Statuses explained
In this page, you will find a description of possible statuses as well as an explanation of what they mean
Types of statuses in a Transaction:
In the transfer, you will find different statuses with different meanings for different parts of the transfer, namely the statuses of the:
- Transfer status: transfer itself
- Agent status: each Agent status
- Policy statuses: your policies and other agents' policies
Transfer Status basic flow
Below is a visual representation of the possible Transfer statuses (in blue) and the corresponding action or API endpoint (in yellow) that triggers each status.
Transfer Status including revert flow
Most of the transitions between statuses should be self-explanatory and only triggered by explicit actions; the few exceptions are listed below:
- On the beneficiary side, a transaction will go to FlaggedSettlement if it is settled by the originator and the beneficiary did not explicitly authorize it;
- A transaction in Authorised/Rejected/Flagged status can go back to Incoming/Outgoing status when an additional counterparty is added or replaced;
Below is a list of all the possible Transfer statuses:
STATUS EXPLANATION
| API Status | Description | Next status |
|---|---|---|
| OUTGOING | New outgoing Transfer | Authorized by authorizing the tx Rejected by rejecting the tx Flagged by flagging the tx Settled by settling the tx |
| INCOMING | New incoming Transfer | Authorized by authorizing the tx Rejected by rejecting the tx Flagged by flagging the tx FlaggedSettlement by settling the tx, status that only applies to the beneficiary side Settled by settling the tx |
| FLAGGED | Transfer flagger for review | Authorized by authorizing the tx Rejected by rejecting the tx Incoming/outgoing by adding an agent FlaggedSettlement by settling the tx; Settled by settling the tx |
| AUTHORIZED | Transfer authorised | Rejected by rejecting the tx Flagged by flagging the tx Incoming/outgoing by adding an agent Settled by settling the tx |
| REJECTED | Transfer rejected | Authorized by authorizing the t Flagged by flagging the tx Incoming/outgoing by adding an agent FlaggedSettlement by settling the tx Settled by settling the tx |
| SETTLED | Transaction settled on-chain | Cleared by clearing a tx FlaggedSettlement by settling a non-authorised tx, looking at the transaction from the beneficiary side RevertRequestedby requesting a revert |
| FLAGGED-SETTLEMENT | Transaction settled but not authorised or explicely flagged | Cleared by clearing a tx Settled by settling the t RevertRequestedby requesting a rever Frozen by freesing the tx |
| FROZEN | Transaction frozen | RevertRequestedby requesting a revert |
| REVERT REQUESTED | Transaction with a request to be reverted | RevertAuthorised by authorising a revert RevertRejected by rejecting a revert RevertFlaggedby getting a rejection on a tx that was asked to be reverted |
| REVERT AUTHORISED | Transaction with a request to be reverted that has been authorised | Revertedby reverting a tx |
| REVERT REJECTED | Transaction with a request to be reverted that has been rejected by the originator on the originator's side | Revertedby reverting a tx |
| REVERT FLAGGED | Transaction with a request to be reverted that has been rejected by the originator on the beneficiary side | Revertedby reverting a tx |
| CLEARED | Transaction credited to the user | Final status |
| REVERTED | Transaction reverted | Final status |
Agent status:
In a Transfer, several agents can be present, and each agent can have a different status.
VASP and Custodian agents
Any VASP or Custodian agent can independently determine their transaction status, which will affect their agent status. e.g. If VASP A authorises their agent status, it will be Authorised
Only two agent statuses that differ from the Transaction statuses are:
| Status | Mening |
|---|---|
| PROCESSING | This is equal to Transfer Status INCOMING and OUTGOING |
| FAILED | This agent status will be returned when the agent has an unresolvable web:did |
Source and Settlement address agents' status
Some Agents will not communicate their status, especially source and settlement addresses, which are Agents in the payment chain. For these Agent types the platform looks at the status of their relationship with the presumed owner, e.g. the VASP or Custodian.
Relationships are always in one of the following states:
| Status | Description |
|---|---|
| UNCONFIRMED | The relationship has not been confirmed or proven |
| CONFIRMED | The relationship has been confirmed |
| PROVEN | The relationship has been cryptographically proven |
See Relationshipsto learn more
TAP policy status:
Tap policies are requirements that each agent can attach to a transfer.
You can learn more about setting up tap policies in the UI here, and an in-depth description is availablehere .
e.g. require address confirmation or provide Travel Rule data are possible TAP policies that will have a specific completition status.
Tap policies status can be:
| Status | Description |
|---|---|
| PENDING | Policy not fulfilled |
| COMPLETED | Policy fulfilled |
| INCOMPLETE | Policy partially fulfilled. This is mainly the case for incomplete sent or received PII in Travel Rule messages, with missing fields according to the jurisdictional requirements (Presentation definitions) |
Updated 2 minutes ago