The Decline or Cancel a Quote operation allows you to reject or cancel an issued quote that has been provided by the FX RFQ service. This action is crucial for managing quotes that are no longer needed or have been deemed unsuitable based on updated business requirements or market conditions.

Capabilities:

  • Decline a Quote: Formally reject a quote that you do not wish to proceed with, ensuring that the quote is no longer available for acceptance.
  • Cancel a Quote: Remove a previously issued quote, preventing any further actions or transactions based on it.

Technical Requirements:

  • Endpoint: /fx/v1.0/quotes/{quoteIdentifier}
  • HTTP Method: PUT
  • authorisation: Requires a valid bearer token obtained via OAuth 2.0.
  • Request Headers:
    • X-Correlation-Id: Optional header for tracking requests.
    • X-Message-Id: Required header for unique identification of the request.
  • Request Body:
    • quoteIdentifier: The unique identifier of the quote to be declined or canceled.
    • status: The desired action, either “CANCEL” or “DECLINE”.

Key Features for Developers:

  • Idempotent Operations: The request is idempotent, meaning repeated requests will have the same effect and response as the first one, preventing unintended side effects.
  • Immediate Effect: Upon a successful decline or cancellation, the quote is rendered inactive, and no further actions can be taken on it.
  • Error Handling: Robust error responses guide developers in troubleshooting issues, such as handling cases where the quote cannot be found or is already inactive.

Example Request:

PUT /fx/v1.0/quotes/MKT-d75a03b5-2d7c-4db0-b30f-bcccc67a4fed HTTP/1.1
Host: api.fileactive.anzgcis.com
authorisation: Bearer <access_token>
Content-Type: application/json
X-Correlation-Id: 71d6fb19-7515-40dc-b045-e17550b67600
X-Message-Id: 71d6fb19-7515-40dc-b045-e17550b67600

{
  "quoteIdentifier": "MKT-d75a03b5-2d7c-4db0-b30f-bcccc67a4fed",
  "status": "CANCEL"
}

Example Response:

On success, the service will confirm the decline or cancellation of the quote with the current status.

{
  "status": "CANCELLED",
  "quoteIdentifier": "MKT-d75a03b5-2d7c-4db0-b30f-bcccc67a4fed"
}

Rate limits and throttling:

By default the following rate limits are applied.

Type TPH (Transactions Per Hour) TPM (Transactions Per Minute) TPS (Transactions Per Second)
Authorisation 10 n/a 2
FX RFQ 500 n/a 10

Rate limiting algorithms:

For most use cases one of two algorithms is implemented for rate limiting.

Fixed Window The system uses a window size of n seconds (typically using human-friendly values, such as 60 or 3600 seconds) to track the fixed window algorithm rate. Each incoming request increments the counter for the window. It discards the request if the counter exceeds a threshold. The current timestamp floor typically defines the windows, so 12:00:03, with a 60-second window length, would be in the 12:00:00 window.

Sliding Window Sliding Window is a hybrid approach. Like the fixed window algorithm, we track a counter for each fixed window. Next, we account for a weighted value of the previous window’s request rate based on the current timestamp to smooth out bursts of traffic.

Sliding window example:

Given a limit of 100 transactions per hour.

  • Window 1 (13:00 - 14:00)
    Between 13:00 - 14:00, 80 requests are received. This is within the 100 tph limit, so all are allowed.

  • Window 2 (14:00 - 15:00)
    By 14:15, 20 requests are received. This is 25% (15 minutes) into window 2, so the weighted average would include 75% from the previous window.

    Request rate: 20 (all requests within window 2) + 60 (75% of requests from window 1) = 80 requests.
    The request rate is still within the 100 tph maximum.

    By 14:30, 75 requests have been received. This is 50% (30 minutes) into window 2, so the weighted average would include 50% from the previous window.

    Request rate: 75 (all requests within window 2) + 40 (50% weighted average from previous window) = 115 requests.
    This exceeds the 100 tph limit, so further requests would return an HTTP 429 (Too Many Requests) status code until the weighted request rate is below the agreed limit.

    By 14:45, no further requests have been made. This is 75% (45 minutes) through window 2.

    Request rate: 75 (current window) + 20 (25% weighted average from previous window) = 95 requests.
    As this is below the 100 tph limit, further requests will be accepted.