Skip to main content
An inbound transaction, or deposit, is money arriving from outside — the mirror of a payout. It needs an open virtual account: an account that exists but has not activated cannot receive anything, and Account opening is what gets it there.

​
What advances it

COMPLETED is not the end. A completed deposit can still be held by a compliance check, and a bank can claw money back after settlement — both are valid transitions out of it. FAILED and REFUNDED are the only states nothing leads out of.FAILED is reachable from PENDING only. A deposit that reached COMPLETED can be held or returned, never failed, so a handler that branches on FAILED is branching on something that can only arrive before settlement finished.

​
What announces it

The account’s own events are in Account opening. These are the deposit’s: virtual_account.deposit_funds_received is the rail-independent signal. Balance behaviour is not uniform across rails, so an integration that watches the balance instead will work on one rail and quietly fail on another.

​
Corridors

A fiat deposit has no separate settlement step, so it is complete the moment it arrives — there is no intermediate state to wait through. A crypto one starts pending and the settlement pipeline advances it.

​
Where an RFI interrupts it

A deposit can raise a request for information against the sub-client that owns the account, and until it resolves, what it blocks stays blocked. The events are the same as in Sub-client verification.
One held deposit blocks every payout from that account. A hold sits in KYT_PENDING, and a decline moves it to KYT_REJECTED — which only compliance can clear.

​
Making one arrive in sandbox

You do not have to wait for a real payer. Simulate a deposit credits the account for real and fires the same webhooks a real deposit does, which is what makes it worth testing against. It exists in sandbox only.

Payout

Money leaving, to a counterparty you saved.