Connect the rails. Preserve what makes them useful.
Different financial systems serve different purposes. SUPA is developing a common coordination layer that can work with eligible institutional capabilities across those environments.
A customer outcome may cross several systems.
An account platform, a currency service and a local payment scheme can each perform its own task well. Friction appears when an instruction must move between them and the information, authority or service state does not follow clearly.
SUPA’s approach is to coordinate the financial journey across participating institutions, rather than require every service to become the same system. The network should use the strengths of the available infrastructure while maintaining a consistent way to follow the customer instruction and the responsibilities attached to it.
A common language without false equivalence.
Two systems may describe similar events differently, or use the same word for different stages. An instruction accepted by one provider can have a different operational meaning from a payment completed by another. Integration must preserve that distinction.
The intended coordination layer maps the information and states required for an agreed service. It should make the journey understandable without flattening important differences in permissions, timing or finality. A common view is valuable when it remains faithful to what the underlying provider actually confirms.
Use real-time capabilities where they fit.
Local real-time deposit and payment schemes can make an important contribution to efficient execution. Their usefulness depends on eligibility, access, available funds and the complete customer requirement. The presence of a fast local rail does not make every preceding or subsequent step immediate.
SUPA’s objective is to help participants coordinate eligible routes with less avoidable friction. The network can consider local execution alongside the other capabilities a journey requires, including agreed currency or liquidity services. Route design begins with the supported institutional relationships, not an assumption that every rail is accessible.
Integrate one coherent service at a time.
A useful first connection has a defined scope: the originating system, the service provider, the information exchanged and the outcome to confirm. Testing should cover both the expected journey and the situations in which the service needs attention.
We discuss these requirements with institutional and technology teams before extending the integration. Specific rail connections, messaging formats, standards and provider compatibility are confirmed individually. This overview describes the architecture’s direction; it does not announce universal support for every network or technical standard.
Different systems, one understandable instruction.
A customer requirement involves a currency service followed by local execution. The institutions involved need to connect the original instruction to both activities, while preserving the meaning of each provider’s acceptance and completion states. Any conditions required between the stages must remain visible.
The result should be a coordinated journey that the originating institution can explain and reconcile. Each underlying service retains its own responsibilities and constraints. Interoperability is the ability to work together correctly, not a claim that the services have become identical.
Good questions.
Clear answers.
Does SUPA replace existing payment rails?
The protocol is intended to coordinate eligible services using participating institutions’ infrastructure, not require every financial activity to move onto a new universal rail.
Which standards and systems are supported?
The exact formats, interfaces and provider connections are confirmed for each integration. No universal compatibility list is implied here.
Why not simply choose the fastest local rail?
The complete instruction also depends on eligibility, funding, currency, review requirements and confirmation of the final outcome.
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.