Make the local strengths work together.
Connect your customer relationship to another institution’s local capability. Build a more coherent journey from the original instruction to the final beneficiary.
The customer sees one financial task.
A customer wants a supplier paid, a business obligation met or funds available in the right place. The institutions involved may see several separate activities: account access, currency conversion, correspondent coordination and local execution. The customer’s experience depends on how well those activities connect.
SUPA Protocol is being developed around that connection. Its purpose is to help institutions use complementary capabilities through bilateral relationships, coordinating the journey without requiring every participant to build every local service. The originating institution can support its customer with a clearer view of the path being used.
Reach through an eligible relationship.
Local access is valuable because it is specific. A participant may understand a domestic payment environment, support a relevant account service or provide a particular financial capability. Access to that strength still depends on the relationship, service conditions and permissions that make its use appropriate.
The network is intended to make these capabilities easier to discover and coordinate. A connection is not universal country coverage, and a technical interface is not a substitute for the institutional agreement. We start with the corridors and services that the participating providers can responsibly support.
Find the route that fits the instruction.
The most useful route balances the customer’s requirement with the capabilities actually available. A local real-time deposit or payment scheme can be an important part of that route, but the complete journey may also involve currency conversion, funding or additional review.
Our design direction is to coordinate those dependencies and reduce avoidable friction. It does not assume that the shortest technical path is always the right financial path. Eligibility, service conditions and the ability to confirm the beneficiary outcome belong in the same decision.
Return a meaningful answer to the customer.
Cross-border operations become harder to explain when each party describes only its own step. An instruction received by one provider does not necessarily mean that the final beneficiary has been credited. A useful shared record preserves those distinctions.
SUPA aims to connect the instruction, the responsible participants and the returned service states. This gives the originating institution a better basis for responding to customer enquiries and resolving exceptions. Coverage, timing and supported confirmation states are agreed for each enabled route rather than promised across an entire network.
Your relationship. A participant’s local execution.
Imagine a financial institution serving a business that needs to pay a supplier outside its direct local reach. A participating institution has an eligible service for the destination. The two institutions establish the relevant relationship and agree how the instruction, any required funding and the result will be handled.
The customer continues to work through its originating institution. The local provider contributes its capability, and the coordinated record helps both parties understand the journey. Faster and more economical execution is the objective; actual availability and timing depend on the selected service and corridor.
Good questions.
Clear answers.
Which countries are available?
Coverage is confirmed during institutional discussions. This website does not publish a universal live corridor list for the developing protocol.
Will every cross-border instruction be instant?
No. A real-time local leg does not remove every dependency in a cross-border journey. The relevant providers confirm the conditions of the complete route.
Does the originating institution keep its client relationship?
That is central to the model: participants contribute complementary services through agreed relationships, rather than treating shared reach as an automatic transfer of the client.
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.