Handle RFIs and Compliance Exceptions

Detect Requests for Information (RFIs), pause blocked money-movement workflows safely, and resume processing without creating duplicate transactions.

Use this guide when a payout, beneficiary, FX trade, onboarding profile, or sub-account operation is delayed because Verto or a partner institution needs additional information before processing can continue.

Before you build RFI handling

Complete these steps before you move live transaction volume:

1. Store every Verto identifier returned by Login, Wallet, Beneficiary, Exchange, Payment, and Onboarding calls.
2. Register webhook endpoints for payout, FX, receive, refund, and wallet statement events.
3. Build an internal exception queue for transactions that are blocked but not failed.
4. Define who in your operations team owns customer communication during an RFI.
5. Confirm your approved review, response, and escalation SLAs with Verto before go-live.

For merged services, store the service-specific identifiers you need for follow-up reads and support escalation:

🛑

Do not treat an RFI as a transient API failure. Retrying with a new idempotency key can create duplicate payout attempts or trigger additional review.

The RFI exception model

An RFI (Request for Information) is a compliance or operational exception where more information is required before a transaction or account action can continue.

RFIs are not the same as validation errors. A validation error means the API rejected the request immediately and you should fix the payload. An RFI means the workflow may already exist, but processing is paused until the requested information is reviewed.

Recommended internal state machine

Use an internal state machine so your backend, operations team, and customer-facing UI agree on what should happen next.

These are recommended internal states for your application. Map them to the status fields and webhook events returned by the relevant Verto endpoint instead of assuming every product returns the same status enum.

Where RFIs can appear

Plan RFI handling anywhere a request can be accepted and then reviewed asynchronously.

Backend handling pattern

When a workflow enters review or RFI handling, pause automation before you create another financial instruction.

1. Move the workflow into an internal exception state such as under_review or rfi_requested.
2. Store the original request payload, Verto identifiers, customer context, and current status.
3. Stop automatic retries for the original write operation.
4. Notify your operations team or customer with the specific information required.
5. Submit the requested information through the approved channel or endpoint for that workflow.
6. Wait for the next webhook or status update before resuming downstream actions.
7. Reconcile the final state before updating balances, payout status, or customer-facing completion messages.

For merged Exchange flows, reconcile with Get FX trade details before retrying a timed-out or review-blocked FX trade. For merged Beneficiary flows, reconcile with Fetch beneficiary by ID before allowing the beneficiary back into payment selection.

What not to retry

Do not retry these actions while an RFI is open unless Verto support or the relevant API state explicitly tells you to create a new request:

• payout creation
• FX trade creation
• beneficiary creation
• beneficiary update for the same requested correction
• wallet creation for the same customer and currency
• sub-account creation for the same downstream customer
• account-detail issuance for the same wallet or account context

If the original API call timed out before you received a response, use the same idempotency key or original paymentId where supported, then reconcile through follow-up reads or webhooks. Do not create a second request with a new identifier until you know the first request did not create a workflow.

Customer-facing messaging

Use neutral language that explains the next action without implying the transaction has failed.

Avoid saying a transaction “failed” unless the final status confirms failure, rejection, cancellation, or refund.

SLA and escalation model

Do not hard-code escalation timers until your approved SLA values are confirmed. Use configurable thresholds so your operations team can adjust them without code changes.

At minimum, define thresholds for:

Each threshold should include an owner, an alert destination, and the identifiers support will need to investigate the case.

Operations checklist

For every RFI case, make sure your team can see:

1. The customer or sub-account affected.
2. The Verto reference, paymentId, wallet ID, beneficiary id, recipient reference, or FX trade reference involved.
3. The current internal state.
4. The latest Verto status or webhook event received.
5. The information requested.
6. The person or team responsible for collecting it.
7. The time the RFI was opened.
8. The time information was submitted.
9. The next escalation deadline.
10. The final resolution.

Troubleshooting

Where to go next

• Send — Build payout flows that pause safely during review.
• Beneficiary Management Guide — Check beneficiary readiness and remediation states.
• Exchange — Track FX trades and settlement state safely.
• Errors and Retries — Decide when to retry and when to stop.
• Webhooks — Process asynchronous status changes without polling.
• Go-Live Requirements — Confirm operational readiness before production rollout.