Resolve a transaction parked for compliance review (sandbox only)
Resolves a transaction parked at the compliance review gate, the customer-facing equivalent of the operator compliance-decision action. outcome: "approve" clears the hold and the transaction resumes (a deposit credits, a withdrawal proceeds) — but only while the case is merely pending review, or at the memo-review park; if AML has already rejected the case, approve returns 409 instead (a rejected verdict can only be terminalized, matching production — reject remains the exit for that park). outcome: "reject" terminalizes the transaction using the transaction type’s default compliance terminal — a deposit freezes, a withdrawal is rejected. Returns 202: the resolution is applied asynchronously; the response body is the transaction as-of the call, so poll the same id (GET /v2/transactions/{id}) to observe the terminal transition. While the transaction is still parked (PENDING), repeating the call is safe — the resolution is deduplicated. A compliance decision is a one-time action: once the transaction has resolved to a terminal state, a repeat returns 409 (already resolved) rather than re-applying, so a retried/duplicate call after resolution is a 409, not a 202 — poll GET /v2/transactions/{id} for the final state. Only DEPOSIT and WITHDRAWAL transactions can be resolved this way; other types return 400.
Authorizations
Path Parameters
Body
approve clears the compliance hold and the transaction resumes (deposit credits / withdrawal proceeds). reject terminalizes the transaction using the transaction type's default compliance terminal (deposit → frozen, withdrawal → rejected).
approve, reject Response
The transaction as-of the compliance resolution
Client-facing view of an outbound withdrawal (debit out of a customer VA/wallet).
^txn_[0-9A-Za-z]{22}$^cus_[0-9A-Za-z]{22}$pending, processing, completed, failed, cancelled One side (source or destination) of a transaction. Discriminated by type.
- Option 1
- Option 2
- Option 3
- Option 4
- Option 5
- Option 6
- Option 7
- Option 8
One side (source or destination) of a transaction. Discriminated by type.
- Option 1
- Option 2
- Option 3
- Option 4
- Option 5
- Option 6
- Option 7
- Option 8
ISO 8601 timestamp
"2026-01-15T09:30:00.000Z"
True when at least one published (non-draft, non-cancelled) RFI targets this transaction. Always present; derived at read time, no stored column.
withdrawal Display name of the customer that owns the transaction: business legal name or individual full name. Same value on the transactions and payouts reads for the same row. Omitted when the customer's identity record hasn't resolved a name yet; per the public omit-don't-null convention, absence is never surfaced as null.
Client-supplied reference, unique per resource within your organization. 1-255 characters from A-Za-z, 0-9, underscore, hyphen, colon, and period — no spaces.
^[A-Za-z0-9_\-:.]{1,255}$Progress signal for a non-terminal transaction, informational only — it does not replace requiresUserSignature, hasRfi, or failureCode for deciding whether your integration needs to act. awaiting_signature: waiting on the required transaction signature (see requiresUserSignature). awaiting_customer_action: further input is needed from your customer — details arrive on the matching event (e.g. transaction.awaiting_sender_information); this is NOT an RFI, hasRfi does not cover it. under_review: compliance, document, or verification review of something already submitted is in progress — usually no action needed; check hasRfi if unsure. settling: funds movement or settlement is in progress, no customer action required — covers long-lived fiat rails like SWIFT that legitimately take days as well as any other non-blocked in-flight state. Omitted once status reaches a terminal value (completed / failed / cancelled). The set of values may grow over time — treat unrecognized values the same as processing.
awaiting_signature, awaiting_customer_action, under_review, settling ISO 8601 timestamp
"2026-01-15T09:30:00.000Z"
user_signature_timeout, user_signature_expired, user_signature_declined, user_signature_rejected_by_provider, crypto_wallet_misconfigured, compliance_hold, compliance_review_rejected, compliance_rejected, returned_by_sender, rail_policy_rejected, insufficient_funds, insufficient_funds_at_settle, rail_unavailable, sender_info_timeout, travel_rule_rejected, provider_rejected, chain_broadcast_failed, roster_changed Human-readable description of failureCode. Defaults to the public error catalog text for the code; sandbox-driven failures may carry the operator-supplied reason instead.
ISO-8601 timestamp when the transaction was cancelled. Present only on status: cancelled.
"2026-01-15T09:30:00.000Z"
Machine-readable cancellation reason. client_cancelled when the client called POST /v2/payouts/:id/cancel; expired is reserved. Omitted on non-cancelled rows. Mirrors orders.cancellationReason.
expired, client_cancelled ^ord_[0-9A-Za-z]{22}$The business purpose declared at payout creation. Drives compliance gating: intercompany requires a whitelisted recipient; other values require supporting documentation.
intercompany, treasury_management, payment_for_goods_or_services, payroll, investments, other, prefunding The most recently published such RFI. Omitted (never null) when hasRfi is false.
^rfi_[0-9A-Za-z]{22}$Position in the per-(wallet, chain) signing queue. Only waiting payouts (position ≥ 1) expose this field; the active/head payout omits it. Absent when the payout is not on the user-signature path or has reached a terminal status.
1 <= x <= 9007199254740991