Skip to main content

​
Overview

Synctera’s platform evaluates every transaction against a set of risk rules — fraud checks and spend controls. In most cases these automated evaluations produce the right outcome, but there are situations where a human reviewer determines that a decline or case was a false positive and the customer should be allowed to proceed. Evaluation overrides give you a controlled way to do this. An override tells the platform: “for this customer (and optionally this account, card, or spend control), skip the specified evaluation for a defined period of time.” Key characteristics:
  • Scoped — each override is tied to a customer_id and can optionally be narrowed to a specific account_id, card_id, spend_control_id, or transaction_id.
  • Typed — the type field indicates which category of evaluation to bypass: FRAUD (fraud-rule evaluation) or SPEND_CONTROL (spend-control limit evaluation).
  • Time-bound — every override has an active_at timestamp and an optional expires_at timestamp so overrides don’t remain in effect indefinitely.
  • Auditable — a reason (minimum 3 characters) is required on creation, providing a clear audit trail for compliance review.

​
When to use evaluation overrides

Common scenarios include:
  • False-positive fraud decline — A customer contacts support because a legitimate transaction was blocked by a fraud rule. After review, an agent creates a FRAUD override so the customer can retry.
  • Temporary spend-control exception — A customer needs to make a one-time large purchase that exceeds their normal spend-control limit. A SPEND_CONTROL override allows the transaction without permanently changing the spend control.
  • Transaction-specific bypass — An override scoped to a transaction_id allows a single previously-declined transaction to be retried.

​
Prerequisites

This guide assumes you have: You should also be familiar with:

​
The evaluation override object

An evaluation override contains the following key fields:
See the API reference for the full request and response schemas.

​
Managing evaluation overrides

1

Create an evaluation override

Use POST /v2/evaluation_overrides. At minimum you must provide a customer_id and a reason.Example: Fraud override for a customerAfter reviewing a fraud case, an agent determines the decline was a false positive and creates an override so the customer can transact normally for the next 24 hours:
Example: Spend-control override for a specific account and spend controlA customer needs to make a one-time purchase that exceeds their weekly card limit. The override is scoped to their specific account and spend control:
The response includes the system-generated id, creation_time, and last_updated_time:
2

List and review overrides

Use GET /v2/evaluation_overrides to list overrides. You can filter by customer, account, card, spend control, transaction, type, or reason.
To retrieve a single override by ID, use GET /v2/evaluation_overrides/{evaluation_override_id}:
3

Update an override

Use PATCH /v2/evaluation_overrides/{evaluation_override_id} to modify an existing override. You can update the active_at, expires_at, and reason fields.For example, to extend an override’s expiration:
4

Delete an override

To remove an override immediately (rather than waiting for it to expire), use DELETE /v2/evaluation_overrides/{evaluation_override_id}:

​
Best practices

Evaluation overrides bypass safety controls. Use them judiciously and always with a clear, documented reason.
  • Set an expiration — Always provide an expires_at value so overrides don’t persist longer than intended. Prefer the shortest window that covers the customer’s need.
  • Scope narrowly — Use account_id, card_id, spend_control_id, or transaction_id to limit the override to only what’s necessary rather than giving a blanket bypass for the customer.
  • Document the reason — Write a clear, specific reason that a compliance reviewer can understand later (e.g., “False positive — customer confirmed wire to known payee” rather than “override”).
  • Review regularly — Use the list endpoint with filters to audit active overrides and ensure none have been left in place longer than needed.
  • Prefer deletion over expiry for immediate revocation — If circumstances change and the override is no longer appropriate, delete it rather than waiting for it to expire.

​
API reference

See the full Evaluation Overrides API reference for request/response schemas and all available parameters: