A direct participant enters the system under its rulebook and assumes defined obligations toward the operator and other participants. These obligations can include technical readiness, funding, security controls, operational availability, reporting and loss allocation.

Direct participation can still involve external infrastructure. A participant may use a service bureau, processor or connectivity provider while retaining its status and responsibilities under the rulebook.

Settlement arrangements also vary. Some direct participants settle through accounts they hold at the settlement institution. Others use an appointed settlement agent while maintaining a direct relationship with the payment system.

An indirect participant reaches the system through a direct participant. The direct participant may submit instructions, receive system messages, provide settlement capacity, manage liquidity or assume scheme obligations on behalf of the indirect participant.

Sponsored access can give the sponsored institution a more visible or technically active role. The sponsor continues to provide specific permissions, settlement resources or risk coverage defined by the arrangement.

These models support banks, payment institutions, fintech companies and other providers that offer payment services without maintaining every capability required for direct participation. They also create a material dependency on the sponsor’s capacity, controls, operating hours and willingness to continue the relationship.

Detailed commercial and operational structures for sponsored financial services belong to banking-as-a-service.

Technical connectivity establishes the ability to exchange instructions or status messages. Financial access establishes the ability to hold or discharge obligations in the settlement arrangement.

The two rights can belong to different institutions. A processor can transmit messages without becoming a participant. A participant can use third-party connectivity while carrying the financial obligation. A payment service provider can serve the end user while a sponsor submits and settles the payment.

Terminology varies across systems. The governing documents determine whether a participant counts as direct, indirect, sponsored, reachable or technically connected.

A customer-facing institution can control the user relationship while holding limited visibility into system processing. A sponsor can receive authoritative system messages while the indirect provider maintains the customer ledger. Reconciliation must connect both record sets.

Payment-system access has become a practical reform priority. The CPMI 2025 monitoring survey, published in May 2026, identifies broader access for non-bank payment service providers and foreign banks as one mechanism for increasing competition and improving cross-border services.

Expanded eligibility changes the operator’s risk perimeter. Each new participant requires admission standards, technical certification, funding arrangements, security controls, incident procedures and a clear path for suspension or orderly exit.

End-user gains depend on the complete operating model: eligibility, technical onboarding, settlement-account access, liquidity support, operating hours and local implementation. A legal right to participate becomes usable access when these elements work together.

Admission, authentication and transaction controls connect this access model to payment controls. The settlement-account relationship connects it to settlement systems.

The BIS description of fast payment systems highlights an important distinction: fast payments require immediate clearing and immediate availability to the beneficiary, while interparticipant settlement can follow different designs.

When the payer or the payer’s authorised provider sends the instruction, the payment follows a push model. Credit transfers and many fast-payment transactions use this structure.

Under a pull model, the payee or collecting institution sends a request based on an existing mandate or transaction authority. Direct debits and many card transactions work this way.

Who initiates the payment changes the evidence the system needs. Push payments rely on payer authorization for the instruction. Pull payments must also prove the payee’s right to collect, the mandate’s scope and the applicable return or dispute procedure.

Before either payment instruction exists, a request-to-pay service can present a structured request for the payer to accept, schedule or reject. Acceptance then creates a separate push payment.

At scheduled times, batch systems process instructions accumulated since the previous cycle. This rhythm supports file controls, aggregate clearing and defined settlement windows.

Continuous processing handles each instruction as it arrives. Participants must remain available, statuses must update in real time, and controls must operate through nights, weekends and holidays.

Exceptions also become immediate operating decisions. If the receiving participant is unavailable, a response is delayed or a limit is exhausted, the next processing event may be only seconds away.

Through a centralised model, instructions pass through a common operator or switch. That infrastructure can apply shared validation, directory, duplicate and status controls.

Across a distributed model, participants or connected infrastructures exchange information through defined interfaces. Common message, security and state rules still bind the arrangement.

Some systems combine central services with participant-held data or processing. A central directory may resolve the receiving institution while participants retain account information; a shared pre-validation service may coordinate requests while the beneficiary institution produces the authoritative response.

Under gross processing, each payment obligation remains individual. Net processing instead aggregates multiple obligations into a resulting debit or credit position.

Clearing and settlement remain separate design choices. One system may clear payments individually and settle accumulated positions later; another may send each accepted payment directly for gross settlement. A third may use prefunded participant positions maintained inside the system.

When the obligation arises, when liquidity becomes committed and which record proves discharge all follow from the applicable rulebook.

Around the payment route, several customer-facing features can change how an instruction begins or how its status is retrieved:

• an alias or proxy resolves a phone number, email address or other identifier to a reachable account;
• a QR code carries initiation or request data;
• an API provides a channel for submission, inquiry or status retrieval;
• open-banking functionality authorises a provider to initiate a payment from an account;
• request-to-pay creates a structured request before authorization;
• confirmation of payee or account verification checks recipient information;
• a wallet stores credentials, value records or access to accounts.

Through each feature, a user, provider or system reaches the payment process differently. Participation, acceptance, clearing and settlement still follow the governing arrangement.

To classify a rail functionally, record:

1. the operator and governing rulebook;
2. the instrument and direction of initiation;
3. the eligible direct and indirect participants;
4. the message and routing arrangement;
5. the processing schedule;
6. the method used to establish participant obligations;
7. the settlement asset, institution and timing;
8. the record that confirms the customer outcome.

This method produces a description that remains accurate as systems add new interfaces and services.

For routes that cross institutions and jurisdictions, cross-border payments traces the complete chain. Detailed message structure and status exchange appear in payment messaging, while settlement systems explains the assets, liquidity and finality behind financial completion. Keeping those functions distinct makes the rail classification durable.

The rulebook gives each system record its operational and legal meaning. A status code becomes authoritative when the rules define the event that produced it, the party that issued it and the consequences for participants.

A payment can carry several identifiers:

• customer or merchant reference;
• end-to-end reference;
• payment instruction identifier;
• system transaction identifier;
• participant reference;
• clearing reference;
• settlement reference;
• account-entry identifier;
• return or recall reference;
• investigation or case identifier.

Each identifier belongs to a defined scope. A customer reference supports the commercial relationship. A system transaction identifier supports operator processing. A settlement reference points to the discharge event. A case identifier connects later investigation activity.

Reliable traceability requires participants to preserve the relationships among these identifiers. Replacing, truncating or reusing a reference can break the chain between customer intent, system processing and financial posting.

The CPMI analysis of the future of financial messaging identifies richer structured data as an enabler of straight-through processing, screening, reporting, funds allocation and reconciliation. These benefits depend on preserving meaning as data crosses institutional boundaries.

Payment records can contain several timestamps:

• the time the customer created the request;
• the time the provider authorised it;
• the time a participant submitted the instruction;
• the time the system received and accepted it;
• the clearing time;
• the settlement time;
• the beneficiary posting time;
• the time a status became visible to the customer.

These timestamps describe different events. They may use different clocks, time zones and precision. Network delays can also cause a later event to appear in a log before an earlier event reaches another institution.

A reliable chronology follows the event definition, issuing authority and linked identifiers. Timestamp order alone provides an incomplete sequence.

A customer-facing status translates several internal events into a simpler message. The provider decides which system event supports labels such as “processing,” “sent,” “delivered” or “completed.”

The word “completed” can therefore refer to system acceptance, interparticipant settlement, beneficiary posting or delivery of a confirmation. A precise operating model maps each customer label to the underlying event and record.

This mapping determines support procedures. It tells the provider which record to inspect, which institution owns the next action and which customer statement the available evidence supports.

Financial systems preserve an audit trail by linking subsequent actions to the original transaction. A return, recall, reversal, refund or recovery usually creates a new instruction or ledger entry with its own identifier and state.

The original record continues to describe the event that occurred. The linked record describes the action taken afterward.

This distinction supports financial reporting, dispute handling and investigation. It also prevents a corrected customer balance from erasing the history of the original payment.

Reconciliation compares records that answer different questions. It can connect:

• the initiating provider’s instruction with system acceptance;
• accepted instructions with clearing positions;
• clearing positions with settlement entries;
• settlement results with participant ledger postings;
• receiving confirmations with beneficiary credits;
• returns and adjustments with the original payment.

A successful reconciliation establishes agreement within the scope of that control. It also exposes missing, duplicated, delayed or inconsistent records.

The design of participant and customer ledgers belongs to ledger architecture. Matching logic, breaks and evidence management belong to reconciliation architecture.

Status: live.

Supplier payments, cash concentration, account funding and other business flows increasingly move through instant-payment systems alongside consumer transfers.

In November 2025, the FedNow Service raised its transaction limit to $10 million. The RTP network also supports transactions up to $10 million; its operator reports growing use in cash concentration, portfolio rebalancing and vendor payments.

At those values, participants need continuous liquidity visibility, calibrated value and velocity limits, stronger authorization evidence and immediate ownership of exceptions.

Even at higher limits, an instant system continues to follow its own access, risk and settlement model. New use cases therefore preserve the distinction between a retail fast-payment arrangement and a system designed specifically for large-value interbank settlement.

Status: live in selected markets and expanding.

Before and around the funds-transfer instruction, modern payment systems can support:

• aliases and proxy directories;
• QR and NFC initiation;
• request-to-pay;
• confirmation of payee;
• recurring-payment mandates;
• delegated payment authority;
• status tracking and confirmation;
• fraud and recovery services.

Request-to-pay and confirmation of payee can increase usability, adoption and safety without changing the underlying transfer mechanism, according to the World Bank analysis of overlay services.

With Pix Automático, a payer provides one authorization for subsequent recurring Pix payments. UPI Circle lets a primary user delegate payment capability while retaining defined control. UK Variable Recurring Payments let authorised providers initiate payments within limits agreed by the account holder.

Each service adds governed objects—requests, mandates, delegations, limits, revocations and consent records. Yet the payment instruction remains a separate event with its own authorization and system state.

Status: live for payee verification; expanding for broader pre-validation; conceptual for portable identity credentials.

Before submission, payee verification checks the relationship between supplied account details and beneficiary information. Broader pre-validation can also test account reachability, routing codes, required purpose data, transaction limits, operating hours, fees, foreign-exchange conditions and expected delivery.

By treating these checks as a system-level capability, the CPMI payment pre-validation study shows how they can reduce failed and misdirected payments. It sets out centralised, decentralised and hybrid data models, each carrying different governance, privacy and availability consequences.

The next development connects identity infrastructure directly to the payment process. In the World Bank’s 2026 ID Meets Instant model, portable payment identity credentials and a shared trust framework support onboarding, recipient verification, authorization and consent-based data exchange.

For now, this identity model remains an architectural proposal. Its significance comes from moving verified identity beyond an institution-specific onboarding record into a reusable credential. Issuance, presentation, revocation and liability would then need common governance.

Status: production and mandatory in major infrastructures.

November 2025 marked the end of coexistence for the relevant MT and ISO 20022 messages after Swift completed the cross-border payment instruction migration. ISO 20022 now supplies the standard format for cross-border payment instructions on Swift.

Format availability leaves a harder task: preserving meaning. Structured party data, identifiers, purpose information and references must survive every internal system and connected infrastructure.

In November 2026, a further milestone is scheduled. Swift will remove fully unstructured postal addresses from relevant cross-border payment messages. Structured or hybrid address data will become necessary for continued automated processing.

The bottleneck therefore shifts to semantic preservation. Systems may exchange ISO 20022 messages and still achieve limited interoperability if their usage rules diverge or participant systems truncate the data.

Status: implementation, with selected services in production.

Interlinking retains existing domestic fast-payment systems and connects them through a standardised interface. Project Nexus is designed to let a domestic operator connect once and reach other participating systems through a common platform.

Domestic participation and settlement arrangements remain in place. Across their boundaries, the link coordinates routing, foreign-exchange information, message conversion, status exchange and operational rules.

Other initiatives coordinate institutions already using correspondent and domestic payment infrastructure. In July 2026, the Swift payment scheme entered production: 26 institutions were processing payments across 25 corridors and 17 countries. The shared framework covers tracking, confirmation, fee and foreign-exchange transparency, plus the use of instant domestic infrastructure for the final part of the route.

Published in May 2026, the CPMI 2025 monitoring survey points to interoperability, broader access, extended operating hours, ISO 20022 harmonisation and standardised APIs as practical requirements for better cross-border outcomes.

Status: emerging, with individual capabilities already in use.

At the point of interaction, NFC gives account-to-account payments a contactless initiation channel familiar from card payments. Offline capability addresses a different condition: the payer, payee or acceptance device lacks continuous connectivity.

For transit, low-connectivity areas and wider fast-payment adoption, the World Bank’s March 2026 report on NFC and offline fast payments treats both functions as important.

Online NFC changes how the payment begins. Offline processing changes when validation and funds movement can occur because the device or provider may accept an instruction before reaching the central system.

During that interval, duplicate spending, altered credentials and accumulated offline value become exposures. Transaction limits, secure credentials, device controls, deferred-upload procedures and clear loss allocation must contain them.

The customer experience may appear instant while the financial event remains deferred. A complete system map records when acceptance occurred, when the instruction reached the payment system and when funds actually moved.

Status: prototype and controlled pilot.

Project Agorá completed a prototype combining tokenised central bank reserves with tokenised commercial bank deposits. The May 2026 BIS report found atomic multi-currency settlement technically feasible within that prototype and set out further work toward real-value testing.

In July 2026, Swift announced that 17 banks were preparing pilot live transactions using tokenised deposits and its blockchain-based ledger.

Across both initiatives, banks retain their own regulated deposit liabilities while shared infrastructure coordinates movement among separate records. The complete transaction still depends on existing messaging, compliance, liquidity and settlement arrangements.

What legal claim does the token represent? The answer must connect ledger access, settlement finality, redemption, interoperability and privacy to an authoritative record when several ledgers participate.

Status: protocol development, pilots and early commercial rollout.

When a software agent discovers products, selects an option and initiates payment, it acts within authority delegated by a person or organisation.

Google’s Agent Payments Protocol preserves the user’s instructions through cryptographically signed mandates. Visa’s Trusted Agent Protocol carries agent identity and trust information through existing web and API interactions. Mastercard has extended Agent Pay to machine-to-machine transactions.

Together, these protocols introduce a controlled software initiator. The underlying payment can continue to use an established card, account-to-account or tokenised arrangement.

For every action, the system must preserve evidence of:

• which agent acted;
• which person or organisation delegated authority;
• the permitted amount, purpose, merchant and time period;
• the condition that triggered payment;
• any required human approval;
• the payment instrument selected;
• revocation and exception rights;
• the party responsible for an action outside the mandate.

Agent identity and mandate evidence consequently enter both payment authorization and dispute resolution.

Policy frameworks have advanced faster than end-user results. The FSB 2025 consolidated progress report found only limited improvement in global cross-border payment outcomes and indicated that the 2027 targets were unlikely to be achieved fully.

Only end-to-end implementation converts a capability into service value. Participant access, operating hours, data quality, liquidity, foreign-exchange availability, final-mile infrastructure and adoption by receiving institutions must align across the complete route.

Feature availability marks technical potential. Production coverage and aligned operating rules make it reliable for the end user.

After a timeout, one participant lacks information; the payment outcome remains unknown.

Before the response path failed, the system may have rejected, accepted, settled or forwarded the instruction. Treating every timeout as failure creates duplicate risk, while treating it as success can leave an unprocessed instruction unresolved.

To contain both risks, the operating model needs an explicit unknown or pending-investigation state. That state invokes a status query, blocks uncontrolled retry and preserves the original identifiers.

On retry, the system may repeat message delivery or create a new payment instruction. Its idempotency rules distinguish the two outcomes.

A safe retry procedure identifies:

• the original customer action;
• the participant instruction identifier;
• the system transaction identifier, where assigned;
• the point reached before communication failed;
• the time for which duplicate protection remains active;
• the response expected from a repeated message.

Before creating a new financial instruction, the participant retrieves the authoritative state. Any new instruction receives its own identity and a documented relationship to the original attempt.

Between participants, settlement records the discharge of an obligation. Posting records a different event: the receiving institution’s liability to its customer.

If settlement completes before posting, the receiving institution carries an operational obligation. If posting occurs before settlement, that institution carries financial exposure.

The displayed customer status should name the event that supports it. Otherwise, “completed” can conceal unresolved institutional states.

A payee-name match records how the supplied name compares with available account data. The result proves neither the payment’s commercial purpose nor the honesty of the person requesting it.

Sanctions screening reports the decision produced from the data supplied to that process. It supplies no proof of system acceptance or settlement.

Authentication shows that defined credentials or factors were used. It cannot show that the customer understood the transaction.

Together, these examples show why control evidence is bounded. The system retains each result alongside the authorization, processing and recovery evidence relevant to the payment.

Although several institutions may participate, one party should own the next controlled action and communication.

When a payment incident opens, response should follow a fixed sequence:

1. preserve the original instruction, messages, identifiers and timestamps;
2. identify the last authoritative state;
3. determine whether a financial obligation arose;
4. determine whether settlement occurred;
5. compare participant and customer-ledger postings;
6. block uncontrolled retry or adjustment;
7. assign the next action under the rulebook;
8. communicate a status supported by the available evidence;
9. reconcile every resulting payment, return or adjustment record;
10. close the incident with a documented financial outcome.

Architecture gaps become visible when teams use different meanings for the same status, lack a query path for uncertain instructions or lose ownership after the payment crosses an institutional boundary.

Continuous monitoring, incident command and recovery sit within payment operations; reconciliation architecture addresses record matching and break resolution; and payment controls defines fraud and regulatory decision models. Together, these functions keep every exception attached to a next controlled action and supporting evidence.

• Payments — the complete infrastructure view across initiation, access, messages, clearing, settlement, records and controls.
• Payment Lifecycle — the end-to-end sequence from customer intent and authorization through processing, posting, reconciliation and exception handling.
• Payment Messaging — message structures, identifiers, status information, ISO 20022 and semantic preservation across institutions.
• Settlement Systems — settlement assets, accounts, liquidity, finality and the discharge of participant obligations.
• Cross-Border Payments — correspondent relationships, foreign exchange, interlinked systems, corridor dependencies and cross-jurisdiction execution.

• Ledger Architecture — financial ledgers, subledgers, postings, balances and the records that establish customer and institutional positions.
• Reconciliation Architecture — matching logic, breaks, evidence and controlled resolution across system, settlement and participant records.
• Payment Operations — monitoring, incident ownership, service continuity, exception queues and operational recovery.

• Banking-as-a-Service — sponsored access, regulated-provider dependencies and the allocation of banking capabilities across institutions.
• Payment Controls — customer authorization, transaction controls, screening, fraud decisions and evidence retained around payment execution.