Follow the instruction all the way through.
A request, an approval, a clearing result and a settled payment are different events. A useful financial network keeps those distinctions visible.
Begin with the purpose and the responsible party.
Before a network can coordinate an instruction, the originating institution needs to understand what its customer has requested and whether the relevant service can support it. The available route, authority and information requirements shape what can happen next.
SUPA’s design follows the instruction from that starting point. The aim is a connected operational journey, in which each participant can identify its own responsibility and understand the relevant state of the shared task. A technical receipt is one event in that journey, not proof that the customer’s objective has been achieved.
Keep clearing and settlement distinct.
Clearing helps establish what is owed and how eligible obligations can be coordinated. Matching or netting may reduce what needs to be settled where the arrangements support it. Settlement is the separate step through which the relevant obligation is discharged under the applicable arrangement.
The protocol is intended to connect these stages without treating them as interchangeable. An instruction may have completed one stage while still awaiting the next. The status returned to a participant should reflect the actual service event, including the confirmation needed before it can be regarded as final.
Give an exception a place in the journey.
Instructions do not always proceed in a straight line. Information may be incomplete, a service may be unavailable or a responsible institution may require review. A coordinated workflow needs to show that condition and identify the party able to address it.
This is also why an unknown outcome should not be treated as a failed operation that can simply be repeated. The integration must first establish what the provider has accepted or completed. Exception handling belongs in the service design, alongside the successful path and the conditions for resuming work.
Close the operational loop.
The original business requirement and the final service outcome need to be reconcilable. The originating institution should be able to connect the result to the customer instruction, while other participants retain the records required for their own roles.
SUPA’s shared record is intended to support this connection. Exact state names, evidence and finality conditions are defined by the enabled service and agreements; this public overview is not a production interface specification. We work through those details with participants as part of integration.
Accepted is not the same as completed.
A provider acknowledges an instruction, then asks for additional information before the next stage can proceed. The originating institution needs to see both facts: the request exists, and it is not yet a completed financial outcome. Its operations team can then resolve the missing information without creating a duplicate request.
Once the relevant service confirms the result, the record connects that event to the original instruction. This distinction supports clearer customer communication and more reliable reconciliation. The precise meaning of completion follows the provider and settlement arrangement, not a generic network label.
Good questions.
Clear answers.
Does a successful API response mean money has arrived?
Not necessarily. The response must be interpreted according to the specific operation and service state; acknowledgement and beneficiary credit are different events.
Can every instruction be cancelled?
No. Cancellation depends on the service and the stage reached. An integration must not assume a completed financial operation can be reversed.
Who defines when settlement is final?
The applicable service, settlement arrangement and legal framework define finality. The protocol’s record should reflect those conditions rather than invent a universal definition.
A closer look.
SUPA Protocol is an institutional network under development. Participation and service availability are subject to bilateral agreements, integration, regulatory permissions and corridor coverage.
Where could we take you?
Tell us what you want to build, connect or make possible.