Connect liquidity to the business need.
Help treasury clients coordinate their financial activity across institutional relationships. Connect the requirement, the available capability and the confirmed outcome.
A wider view of the customer’s working world.
Your customer’s business may extend beyond the accounts and services your institution provides directly. Supplier obligations, operating balances and currency requirements can sit across different relationships. A team can have sufficient resources overall and still spend considerable effort arranging the specific movement it needs.
SUPA is developing a coordination layer that allows participating institutions to combine eligible capabilities around that business requirement. The aim is to help you support more of the customer’s financial journey through agreed relationships, while retaining your role and the responsibilities attached to it.
Coordinate without confusing ownership.
A connected view of financial activity is not the same thing as a single pool of funds. Balances remain subject to the relevant account arrangements, permissions and provider responsibilities. An institution cannot use another participant’s liquidity simply because both are connected to a network.
The protocol’s role is to coordinate supported instructions and eligible institutional services. Where a liquidity movement, currency service or settlement arrangement is available, its conditions must be explicit. This gives the treasury workflow a usable connection between what the customer needs and what the participating providers can actually deliver.
Consider the whole movement.
The usefulness of a treasury instruction depends on more than the first transfer. The destination, currency, availability of funds and confirmation of the result all matter. A route that appears convenient at one stage may not meet the final business requirement.
Through bilateral relationships, participants can assess supported capabilities together. Local access may complement another institution’s customer relationship or specialist service. Eligible real-time routes can be considered where they fit the complete instruction, rather than treated as a guarantee that every cross-border journey will be immediate.
Make the next action clear.
Treasury teams need to distinguish a planned movement from an accepted instruction and a confirmed result. When something requires review, they need to know which part of the journey needs attention. That visibility helps the originating institution give a more useful answer to its customer.
Our starting point is a specific operational requirement. We discuss the participating relationships, the information needed, the capabilities involved and the evidence required to close the task. The resulting scope can then be integrated and tested before a broader set of treasury journeys is considered.
A business obligation, coordinated across relationships.
A corporate customer asks its institution to support an upcoming obligation in a market served by another participant. The originating institution identifies the eligible relationship and supported services needed to reach the beneficiary. Any currency conversion or liquidity arrangement is part of that agreed scope, not an assumed network entitlement.
The instruction can then follow the supported route, with the outcome connected back to the customer’s business purpose. The value is coordinated service: fewer disconnected operational conversations and a clearer account of what still needs to happen. This is an illustrative future network workflow.
Good questions.
Clear answers.
Does connection create a global cash pool?
No. Account ownership, access and any pooling arrangement remain separately governed by the relevant institutions and agreements.
Can we use other participants’ liquidity automatically?
No. Access requires an eligible service and an agreed institutional relationship with the relevant conditions.
Where should a treasury discussion begin?
With a specific customer need: the entities involved, the intended destination, the service required and the operational outcome your team needs to confirm.
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.