Build the payment model you need, and keep it yours

Definition

Owning a payment architecture means that an institution decides how its payment flow works and controls the resources the flow depends on – accounts and keys, rules and limits, records, integrations and the choice of counterparties – so that it can change or move any of them without a third party’s permission. It does not mean building or operating every component. Licensed partners and service providers remain part of the flow; the institution selects them, connects them and can replace them.

Institutions often meet new settlement technology first as a packaged service. A provider runs the process, holds the integration and prices each change. That can be a sensible way to start: it is quick, and someone else carries the operating burden. It becomes a constraint when the business needs something the package does not offer, when the provider’s roadmap diverges from the institution’s, or when the cost of staying exceeds the cost of the work the service replaced.

The alternative is not to build everything in-house. It is to keep the decisions and the resources that define the flow inside the institution, and to treat every third party – issuer, network, custodian, screening provider, technology vendor – as a component that can be changed. The sections below set out what that means in practice, what it costs, and when a managed service remains the better answer.

What a closed process costs

A closed process is one in which a third party decides how the flow works and the institution cannot inspect, change or move it. The visible cost is the fee. The larger costs sit elsewhere: change requests priced and scheduled by the provider, product decisions taken on someone else’s roadmap, and an exit that becomes more expensive with every year of integration.

The dependency usually takes three forms. Commercial: the provider sets the price of volume, of new corridors and of every change. Operational: the provider’s release cycle, cut-offs and support hours become the institution’s. Informational: transaction data, reconciliation records and audit trails arrive in the form, and at the time, the provider chooses.

Dependency also concentrates risk. If the provider changes its terms, withdraws from a market or suffers an outage, the institution’s payment flow changes with it. For a regulated institution that is a supervisory question as much as a commercial one: outsourcing a process does not outsource accountability for it, and in the EU, outsourcing rules expect an exit strategy for critical or important functions.

Design to the business, not to the product

Every payment flow has its own shape: which currencies it carries, which institutions sit on each leg, who funds the position, which checks run where and how the result is reconciled. A packaged service answers those questions once, for all of its customers. An institution that owns its architecture answers them for its own flow.

That freedom is practical rather than ideological. It lets an institution choose the settlement asset that fits its legal perimeter, set its own controls and limits, and decide where the incumbent rail remains the better answer. The design follows the use case; the technology follows the design.

Compare the dependency a packaged service creates with the work ownership requires.

Control the resources the model runs on

Owning the model means controlling the resources it depends on, so that the institution can inspect, change or move them when regulation, risk appetite or the business changes. Five resources decide whether an institution owns its flow or rents it.

• Keys and accounts

  The institution controls its settlement accounts and the keys that sign for them, directly or through a custodian it appoints, with its own governance for access, rotation and recovery.

• Rules and controls

  Limits, permissions and payment rules are set by the institution and can be changed when policy, regulation or risk appetite changes.

• Data and records

  Transaction records and reconciliation data are available to the institution directly, not only through a provider’s reports.

• Integrations

  Connections to core banking, treasury, screening and payout systems are documented and owned, so they can be extended or moved.

• Counterparties

  Issuers, networks and payout partners are chosen by the institution and can be added or replaced as the business requires.

None of these requires the institution to operate every component itself. A custodian can hold keys under the institution’s governance; a vendor can build an integration the institution owns and documents. The test is whether the institution can act on the resource without asking for permission.

Compatible with third parties, by choice

Owning the architecture does not mean building everything. Licensed partners, payout networks, custody providers and screening services all have a place in a production flow, and the business will often need them. The difference is where they sit: as components the institution selects, connects and can replace, rather than as a closed process the institution must fit around.

Open interfaces and open-source software make this practical. Xahau’s server software, xahaud, is open source: an institution can run its own node, read the shared record directly and connect counterparties that meet its requirements, rather than reaching the ledger only through one provider’s interface. The same principle applies to the settlement asset. Instrument choice belongs to the institution, made against its currency, counterparties and legal perimeter, not inherited from a provider’s default.

Compatibility runs both ways. If the institutions on the other side of a flow require a different rail, interoperability takes precedence over preference. An architecture the institution owns is also easier to connect to a second rail than one it rents, because the integrations and records are already its own.

In practice: Europe → Ethiopia

The corridor that TerraPay, Cooperative Bank of Oromia and Quantoz Payments launched on 6 May 2026 shows the allocation in a live flow. TerraPay operates the cross-border payments network on the sending side. Quantoz Payments, an electronic money institution supervised by De Nederlandsche Bank, provides the regulated euro e-money that settles between institutions. Xahau is the settlement ledger. Cooperative Bank of Oromia connects the settlement leg to domestic banking and payout.

Each of those functions sits with the institution responsible for it, and TerraPay’s announcement is explicit about the regulatory side. The corridor was developed in collaboration with INFTF, whose role was the regulatory and technical framework; INFTF holds no licence and issues no money in the flow. Another corridor will allocate the roles differently, but the test is the same: the institution that carries the responsibility for a leg should also hold the function.

When a managed service is the better answer

Ownership has costs of its own: people to operate the flow, governance for keys and controls, and the discipline to maintain what has been built. Where volumes are small, the corridor is well served by existing rails, or the institution has no appetite to operate settlement infrastructure, a managed service or the incumbent rail is a legitimate outcome.

A managed service can also be a stage rather than a destination. An institution can start on one while it learns the flow, provided the contract keeps the data, the integrations and the exit within reach. The aim is a deliberate choice, made with a clear view of the dependency it creates.

Questions to ask before signing

Whether the flow is built in-house, with partners or on a managed service, the answers show how much of it the institution would own.

1. 01Can we export the full transaction and reconciliation history without the provider’s help?
2. 02Who controls the keys to our settlement accounts, and how would that control move?
3. 03Can we change a limit, permission or counterparty without a change request?
4. 04Are our integrations documented well enough for another team to take over?
5. 05What happens to the flow if the provider changes its terms or leaves the market?
6. 06Can we add a second issuer, network or payout partner without rebuilding the flow?

How INFTF works with institutions

INFTF contributes architecture, prototypes and technical support for blockchain integrations, and connects the institutions needed to make a payment flow work. The work is pro bono, so there is no fee or subscription that ties an institution to INFTF.

The business parties own and operate the resulting service. They manage issuance, compliance checks and production operations, and they keep the architecture, the integrations and the freedom to change them. Our role is to help an institution build the model it needs and leave it able to run, adapt and extend that model on its own terms.