Statuses

Every institution on a transfer keeps its own state, and no state is shared between them. Two statuses matter most: your own, My Status in the dashboard, and the transaction status, which combines every institution’s status with the settlement. It is normal for the two to differ while a transfer is in progress.

My Status and Transaction status, together

Read the two together to know where a transfer stands and whether it waits on you.

Your status (My Status)

Your status says where your institution stands on the transfer. It is public, so every institution on the transfer sees the status of every other one, but not why.

Your status can still change after it is Authorized. When something on the transfer changes and your policies run again, a new flag or a reopened requirement puts it back to Pending, and a rejection makes it Rejected.

When your team authorizes a transfer while a flag or a requirement is still open, the dashboard lists what will be overridden and asks for a reason. Your status becomes Authorized straight away and every open requirement your institution set becomes Skipped. Requirements another institution set for you stay open until you meet them, and the hold on personal data is never skipped.

Transaction status

The transaction status says where the transfer stands across every institution. Notabene derives it from every institution’s status and the settlement. When an institution has canceled, the transfer is Canceled even if another one rejected it.

1. Before settlement: a transfer is Active while at least one institution is still Pending, and ReadyToSettle once every institution is Authorized. It ends before settlement as Rejected or Canceled when an institution rejects it or the originator cancels it.
2. Settlement: when the sender records the transaction hash, a ReadyToSettle transfer becomes Settled. When the funds move before everyone authorized, it is SettledIncompleteAuthorization, and it becomes Settled once every institution is Authorized.
3. Revert: when funds have to come back, a settled transfer goes to RevertRequested, then RevertAuthorized and Reverted. A revert can also end as RevertedIncompleteAuthorization, RevertRejected or RevertCanceled.

Once a transfer is settled, it never returns to a status before settlement. Settled can still move back to SettledIncompleteAuthorization, for example when an institution rejects the transfer after settlement over a compliance issue, and returning the funds then takes a revert.

Reverts

To return the funds of a settled transfer, your institution requests a revert, with a reason that is shared with the counterparty. The revert is a new transfer linked to the original, and the funds go back to the address they came from or to one you give. The counterparty authorizes it like any other transfer, and the original transfer’s status follows it.

Other statuses on a transfer

Under the two main statuses, three more say what is still open and why.

Pending appears three times: your status waits on your side, a requirement waits on the institution that must meet it, and your send status waits on the counterparty.

Requirement statuses

A requirement is something that must happen before an institution can be authorized, such as receiving the Travel Rule data or confirming a deposit address. Every requirement has an institution that sets it and an institution that must satisfy it, and each has its own status.

Only the institution that set a requirement can skip it or reject it by hand, and every skip is recorded in your audit log, whatever its cause. The institution asked to meet it can still answer with a rejection, such as an address it does not own. Requirements lists each requirement and who meets it.

Your policies’ verdict

Your policies give each transfer a verdict: approve, flag or reject. Because the verdict is private, the other institutions only see its effect on your status, and a flag keeps that status Pending until a person on your team decides. Your audit log records every verdict.

Your send status

Your send status, which only you see, says whether your Travel Rule data has reached each counterparty: Sent, or Pending while the counterparty cannot receive it. Sending happens in two steps: the transfer details go first, and your customer’s personal data is held until the counterparty confirms that the destination address belongs to its customer. A counterparty still on Transact v1 receives all the data in the first message.

The hold on personal data cannot be skipped, so a transfer can be Authorized while no personal data has been sent yet. Sending and authorizing are independent, and your status does not wait for your data to be sent unless you turned on the requirement to transmit Travel Rule data.

Statuses on other records

For your developers

Statuses and decisions in the API shows where each status is in the API, the events that report a change, and the calls behind each decision.