USA Payment and Collection Participants. A deep participant map covering customers, account-holding institutions, ACH roles, Federal Reserve and TCH access, correspondents, instant-payment funding and connectivity, cards, checks, processors, controls, settlement and operational ownership.
The easiest way to misunderstand a US payment is to name only the payer, the payee and the network. Real payments involve more parties than the customer sees. Some participants create the instruction. Some hold the accounts. Some validate or transform data. Some operate the network. Some provide settlement accounts or liquidity. Some act through a correspondent or sponsor. Some never touch the money but still determine whether the payment is authorised, screened, posted, reported and reconciled correctly.
This chapter is deliberately about participants and responsibilities, not detailed rail mechanics. Chapter 1 built the map of the US payments and collections ecosystem. Chapter 2 now asks a different question:
Who is actually doing what at every point in that ecosystem, and who remains accountable when another party performs the work?
That distinction matters to business analysts, product owners, architects, developers, testers and operations teams because a vague requirement such as “the bank sends the payment to FedNow” hides several real questions. Which bank? Is it a direct participant? Which routing number is reachable? Who provides settlement? Is a service provider connecting on its behalf? Who owns the customer account? Who performs fraud controls? Who posts the beneficiary? Who reports the status? Who investigates when the customer says the money is missing?
For a roughly 60-minute core session, spend about 35 minutes on Sections 1–2, Sections 4–9 and Sections 13–14. For the next 10 minutes, use the chapter’s three diagrams to name the accountable institution at each handoff. Use 10 minutes to work through one participant story in Section 15, then spend the final 5 minutes explaining: If a processor performs a step, who still owns the bank's responsibility for it? Treat these timings as a study guide. The remaining sections, additional cases and extended reference material are follow-up study; completing the whole chapter takes longer.
Chapter navigator
- Why participant mapping comes before payment design
- Payer, payee, originator, receiver and customer roles
- Account-holding financial institutions: where customer responsibility begins
- ACH participants: Originator, ODFI, operator, RDFI and Receiver
- Federal Reserve Banks: operator, settlement infrastructure and master-account layer
- The Clearing House: EPN, CHIPS and RTP have different participant models
- Fedwire participants, correspondents and high-value client payments
- RTP and FedNow: participant capability, funding and connectivity
- Card participants: cardholder, merchant, gateway, acquirer, network and issuer
- Check and lockbox participants: paper at the edge, institutions in the middle
- Correspondent, respondent, sponsor and intermediary institutions
- Fintechs, processors, gateways, PayFacs and platform intermediaries
- Control participants: fraud, sanctions, AML, treasury and operations
- Settlement, liquidity, accounting, reporting and reconciliation participants
- Four participant stories: how the chain changes by payment type
- The practitioner participant map: requirements, testing and ownership
1. Why participant mapping comes before payment design
When a customer presses “Pay,” the customer normally sees only a channel and a status. The bank sees a chain of responsibilities.
The first participant is the party with the economic intent. A consumer wants to pay a utility. A corporation wants to pay a supplier. A merchant wants to collect a sale. A biller wants to collect an invoice. A government agency wants to disburse benefits. A treasury desk wants to move liquidity. Those business actors create the reason for the payment, but they do not necessarily operate the network that moves it.
The second layer is the account relationship. A financial institution holds the payer’s or payee’s account, applies product terms, controls account access and creates ledger postings. In an on-us transfer, one institution may hold both accounts. In an interbank payment, at least two account-holding institutions are normally involved.
The third layer is processing and orchestration. A bank may run this itself or use processors, gateways, core vendors, payment hubs, service bureaus or third-party providers. These parties can perform technology functions without becoming the customer’s bank or the settlement institution.
The fourth layer is the clearing or payment-system operator. Nacha governs the ACH Network rules while FedACH and EPN act as ACH operators. The Federal Reserve Banks operate Fedwire Funds Service and FedNow. The Clearing House operates CHIPS and RTP. Card networks operate their card schemes. Check image exchange can involve Federal Reserve Check Services, The Clearing House Image Exchange and direct/private arrangements.
The fifth layer is settlement. This is where institutional obligations are actually discharged. A participant may settle through its own Federal Reserve master account, through another depository institution’s master account, through a prefunded arrangement, through a settlement agent or through an account relationship specific to the network.
The sixth layer is evidence. Operations, reconciliation, accounting, reporting and investigations need to prove that the customer instruction, network event, settlement movement and ledger entries belong to the same transaction.
A powerful BA rule follows from this map:
Do not ask only “which system sends the payment?” Ask “which participant owns each obligation, which participant performs each activity, and which participant remains accountable if that activity is outsourced?”
This distinction between performing a task and owning the responsibility becomes increasingly important as US payment models use sponsor banks, third-party senders, processors, connection agents, settlement agents, fintech platforms and vendor gateways.
A bank may outsource file creation, network connectivity or customer-channel technology. It cannot outsource away every obligation attached to being the financial institution, ODFI, RDFI, issuer, acquirer, network participant or account provider.
That is why participant mapping belongs at the beginning of design.
2. Payer, payee, originator, receiver and customer roles
The words “sender” and “receiver” look simple until different rails use different formal terms.
At business level, the payer is the party whose economic obligation is being discharged. The payee or beneficiary is the party intended to receive value. For a consumer bill, the consumer is the payer and the utility is the payee. For payroll, the employer is the payer and the employee is the payee. For a card purchase, the cardholder is the payer from an economic perspective and the merchant is the seller collecting the funds, even though card processing introduces issuer, acquirer and network roles between them.
ACH uses formal terms that need precision. The Originator is the party that initiates an ACH entry under the relevant authorisation and arrangement. The Receiver is the party whose account is credited or debited by the ACH entry. A Receiver is not always receiving money. In an ACH debit, the Receiver’s account is debited. That is why relying on everyday English instead of the formal ACH role can cause requirements errors.
For an ACH credit payroll transaction, the employer is the Originator and the employee is the Receiver. For an ACH debit collection, the biller may be the Originator and the consumer whose account is debited is the Receiver.
Instant payments use credit-push logic. The payer authorises a credit transfer from the sending institution toward the receiving institution. A Request for Payment changes the experience but not the direction of the eventual transfer. The biller can send a request, but the payer still approves the credit push. The party requesting money and the party initiating the actual funds transfer are therefore not automatically the same participant.
Wires similarly require a distinction between the originator of the business instruction, the sending bank, possible intermediary banks and the beneficiary bank. The customer may tell its bank to pay a supplier. The customer does not directly transmit a Fedwire or CHIPS message simply because the corporate channel displays a “wire” product.
In cards, the customer roles are cardholder and merchant. The cardholder presents a credential or token. The merchant presents the transaction into the acceptance chain. The financial institutions and networks then perform authorisation, clearing and settlement functions.
In checks, the drawer writes the check, the payee receives it, the bank of first deposit accepts it for deposit, and the paying bank is the institution on which the check is drawn.
The practical requirement is to model the role name in the context of the rail. Avoid one generic “senderParty” and “receiverParty” model if later processing needs to distinguish Originator, Receiver, cardholder, merchant, drawer, payee, debtor, creditor, sending institution and beneficiary institution.
The business meaning can remain consistent while the formal network role changes.
3. Account-holding financial institutions: where customer responsibility begins
The customer’s bank or credit union is usually the most important participant because it owns the customer account relationship. That institution knows the account status, product entitlement, available balance, customer identity, service limits and posting rules.
On the sending side, the account-holding institution determines whether the customer may initiate the requested transaction. It authenticates the customer or channel, verifies entitlements, validates the debit account, applies limits, invokes fraud and compliance controls and decides whether an instruction is eligible for release.
On the receiving side, the account-holding institution receives the network outcome, determines whether the destination account is valid and eligible, posts the funds or item according to product and network rules, applies availability treatment, creates customer reporting and supports later enquiries.
This is why an external network acknowledgement is not enough to declare a customer payment complete. A payment can be accepted by a network and still need beneficiary-account posting. A check can be deposited but still remain subject to return risk. A card transaction can be authorised but the merchant has not yet been funded. The account-holding institution connects network events to the customer’s actual balance.
A US financial institution may access Federal Reserve services using its own master account or, where permitted, settle through the master account of another depository institution. The Federal Reserve Board’s Master Account and Services Database explicitly recognises both forms of access. That means “uses a Federal Reserve service” and “has its own master account” are not identical statements.
The same separation appears in private systems. A financial institution can offer a payment service to customers without being a direct participant in every underlying network. It may use a correspondent, respondent arrangement, funding agent, settlement agent or technology provider.
From a BA perspective, always identify:
- Who holds the payer account?
- Who holds the payee account?
- Who owns customer authentication and entitlement?
- Who decides the debit can be posted?
- Who decides the credit can be posted?
- Which institution owns customer-facing errors and complaints?
- Which institution has the contractual payment product relationship?
- Which institution participates directly in the network, if any?
- Which institution actually settles the interbank position?
Do not assume those answers are all the same legal entity.
When both accounts are at one bank, the institution may complete an on-us transfer without external clearing. Yet the same internal controls still matter: customer authority, account status, fraud, ledger posting, fees, notification, reporting and audit.
The absence of an external network does not remove participant responsibilities. It simply concentrates them inside one institution.
4. ACH participants: Originator, ODFI, operator, RDFI and Receiver
ACH has one of the clearest formal participant structures in US payments, and it is worth learning accurately because the role names appear directly in rules, operations and investigations.
The basic chain is:
Originator → ODFI → ACH Operator → RDFI → Receiver
The Originator is the business, government entity or other party initiating the ACH entry under the required authorisation and agreement.
The Originating Depository Financial Institution (ODFI) is the financial institution that receives entries from an Originator or qualifying intermediary and transmits them into the ACH Network. The ODFI is not merely a file-forwarding system. It has obligations under the Nacha Operating Rules, including obligations around its origination relationships, risk controls and rule compliance.
The ACH Operator receives ACH entries from ODFIs, processes them and distributes entries to RDFIs. In the United States the two ACH operators are the Federal Reserve’s FedACH service and The Clearing House’s Electronic Payments Network, EPN. They interoperate so that an ODFI sending through one operator can reach an RDFI using the other operator.
The Receiving Depository Financial Institution (RDFI) receives ACH entries and posts them to Receiver accounts according to the applicable rules and account relationship.
The Receiver is the party whose account receives the credit or debit entry.
Now add the third-party layer.
A Third-Party Service Provider (TPSP) performs ACH-related functions on behalf of an Originator, ODFI, RDFI or another relevant participant. A TPSP might create files, transmit entries, operate processing software or perform other ACH functions.
A Third-Party Sender (TPS) is a specific type of TPSP. Nacha describes a TPS as acting on behalf of an Originator to transmit entries through an ODFI when the Originator does not have a direct origination agreement with that ODFI. The contractual relationships are therefore different from a simple Originator-to-ODFI model.
A Nested Third-Party Sender originates through another TPS rather than directly through the ODFI. This adds another responsibility and due-diligence layer.
These distinctions matter because two technology platforms may look almost identical to the end customer but occupy different ACH roles based on contractual relationships and what they actually do.
Consider a payroll platform. It may simply prepare an ACH file for a corporate that has its own origination agreement with its bank. In that arrangement the platform may be acting as a service provider. In another model the platform may transmit entries for many corporate Originators through its own relationship with an ODFI, potentially making its formal role different.
The participant role cannot be determined from the user interface alone.
Nacha’s 2026 fraud-monitoring changes reinforce this point. Different participant categories have explicit responsibilities depending on whether they are ODFIs, non-consumer Originators, Third-Party Senders, TPSPs or RDFIs. A bank designing controls must know what role each entity occupies.
In requirements, capture participant identity at both file and transaction level where needed. If a Third-Party Sender submits entries for multiple Originators, operations and risk teams may need to distinguish the TPS, underlying Originator, ODFI, company identification and entry-level Receiver.
When an ACH item is returned, those same identities help determine who receives the return, who informs the Originator, who repairs customer data and who owns the risk decision.
Participant modelling is therefore not just documentation. It is the foundation for controls, reporting, returns and accountability.
5. Federal Reserve Banks: operator, settlement infrastructure and master-account layer
The Federal Reserve Banks play several distinct roles in US payments. Treating “the Fed” as one generic participant hides important differences.
First, the Federal Reserve Banks operate payment services. These include Fedwire Funds Service, FedACH, FedNow Service, National Settlement Service and Check Services.
Second, Federal Reserve master accounts provide the central-bank money layer used to settle many interbank obligations. A financial institution may settle directly in its own master account or access Federal Reserve services while settling through another depository institution’s master account where the relevant arrangements permit.
Third, the Federal Reserve can provide services used by private clearing arrangements. National Settlement Service is a good example. A settlement agent submits a multilateral settlement file so debit and credit positions can be posted to the master accounts of settling institutions. The private arrangement may calculate the positions, but the final central-bank postings occur through the Federal Reserve service.
Fourth, the Federal Reserve provides operating rules, circulars and service-specific requirements that define participant responsibilities for its services.
For Fedwire Funds Service, participants can send or receive payments for themselves or on behalf of clients and can settle obligations with other financial institutions or clearing arrangements. The participant is therefore not merely forwarding customer instructions; it is using a high-value settlement service connected to its Federal Reserve account relationship.
For FedNow, the participant ecosystem includes participating financial institutions, settlement agents, liquidity providers and certified service providers. The Federal Reserve publishes separate lists for these categories because they are not interchangeable roles.
A participating financial institution offers the relevant FedNow service capabilities.
A settlement agent can support settlement arrangements for another institution depending on the service model.
A liquidity provider can support liquidity transfers needed by participants.
A certified service provider may provide connectivity or processing capabilities after completing required testing, but being a service provider is not the same as becoming the customer’s bank or the settlement institution.
This separation is critical to architecture. A bank may use a vendor gateway to connect to FedNow. The vendor may host message transformation, monitoring and connectivity. The bank still needs to know which institution’s account settles, who owns customer controls and who is accountable for payment decisions.
The Federal Reserve participant layer therefore teaches one of the most important lessons in this chapter:
technical connectivity, payment participation and settlement-account ownership are three different concepts.
6. The Clearing House: EPN, CHIPS and RTP have different participant models
The Clearing House operates several payment infrastructures, but the participant model is not identical across them.
EPN is an ACH operator. Institutions participate in ACH under Nacha rules, and EPN processes ACH entries as the private-sector ACH operator interoperating with FedACH. For the customer, an ACH credit or debit does not normally expose which operator processed the transaction. For bank operations and settlement, that operator relationship matters.
CHIPS is a high-value USD clearing and settlement system designed for financial institutions with significant wire activity. As of 2026, The Clearing House reports 43 direct participant banks. Institutions that do not participate directly can still access CHIPS payment capability through correspondent or respondent relationships with CHIPS participants.
That statement is extremely important. A corporate customer can receive a payment whose USD path uses CHIPS even though neither the corporate nor its local customer-facing bank is necessarily a direct CHIPS participant.
The direct participant owns its relationship with the CHIPS network, submits or receives payment instructions according to CHIPS rules, manages its CHIPS liquidity and supports correspondent/respondent flows for other institutions where applicable.
RTP is a 24/7 instant-payment network with its own Participation Rules, Operating Rules, participant agreements, funding arrangements and technology-provider ecosystem.
The RTP document library separately identifies participants and routing/transit numbers, technology providers, funding participants, non-funding participants, funding agents and connection arrangements. Again, a customer-facing bank, network participant, funding participant and technology provider are not necessarily the same entity.
This means the phrase “the bank is on RTP” is too vague for production design. Ask:
- Can it receive?
- Can it send?
- Which routing numbers are enabled?
- Is it a funding participant or non-funding participant?
- Is a funding agent involved?
- Does it connect directly or through a technology/connection provider?
- Which entity receives network messages?
- Which entity manages prefunded settlement capacity?
- Who handles reconciliation and exceptions?
Those questions are about participant capability, not merely membership.
The Clearing House examples reinforce the same general rule seen with Federal Reserve services: network membership, customer product capability, technology connection and settlement responsibility must be modelled separately.
7. Fedwire participants, correspondents and high-value client payments
Fedwire is often described as a bank-to-bank wire system, but a real client payment can involve more parties.
Start with a corporation instructing Bank A to pay a beneficiary at Bank B.
If both Bank A and Bank B can exchange the required Fedwire payment directly through their Federal Reserve service access, the participant chain is relatively short:
Corporate originator → Bank A → Fedwire → Bank B → Beneficiary
But the customer relationship still contains additional internal participants: corporate channel, wire operations, fraud, sanctions, treasury/liquidity, core ledger, reporting and reconciliation.
Now consider a smaller financial institution that offers wires but does not perform every part of the Fedwire chain itself. It may use a correspondent bank. The customer instructs its own bank, but the correspondent may be the institution that actually transmits the Fedwire payment or provides settlement access.
The chain can become:
Customer → Respondent/customer bank → Correspondent bank → Fedwire → Receiving institution/correspondent → Beneficiary bank → Beneficiary
The exact path depends on the institutions and account relationships.
The terms correspondent and respondent describe a banking relationship in which one institution provides services to another. In cross-border banking, a correspondent may hold accounts and execute payments for respondent institutions. In domestic contexts, correspondent arrangements can also provide access or settlement services.
For the BA, the critical question is not to memorise every correspondent pattern. It is to identify where the customer’s bank hands responsibility to another institution and what evidence crosses that boundary.
The sending customer still expects its own bank to answer: Was my payment accepted? When was it sent? What reference proves it? If a correspondent transmitted the network message, the customer-facing bank needs access to that status.
The receiving side has the same issue. A beneficiary bank may receive through another relationship before crediting the final account. Investigations need to identify the complete participant chain without presenting the customer with internal complexity unless it is relevant.
High-value participant mapping must also consider sanctions screening. Different banks in a chain may independently apply their own compliance controls based on applicable law and policy. A payment delayed at an intermediary is not the same as a payment rejected by the beneficiary bank.
This is why cross-bank status models should not collapse every delay into “pending.”
8. RTP and FedNow: participant capability, funding and connectivity
Instant payments make participant precision especially important because execution decisions happen in seconds.
A typical instant credit transfer has a payer, sending financial institution, network, receiving financial institution and payee. But behind those visible roles can sit connection providers, funding agents, settlement agents, liquidity providers and core processors.
For FedNow, the Federal Reserve publishes current lists of participating financial institutions, routing transit numbers, settlement agents and liquidity providers, and certified service providers. These lists are updated separately because each category describes a different capability.
For RTP, The Clearing House publishes participant and routing information, technology-provider information and documents for funding participants, non-funding participants and funding agents.
Imagine a community bank offering instant receipt capability through a core-banking vendor. The bank may be the account-holding institution and network participant while the vendor provides technical connectivity. A separate settlement or liquidity arrangement may support the bank’s payment activity.
Now imagine a fintech application that advertises instant payouts. The fintech may not be the institution participating directly in RTP or FedNow. A sponsor or partner bank may hold accounts and access the network, while the fintech provides the user experience and business orchestration.
Those two models can produce a similar customer screen but create very different contractual, compliance, settlement and operational responsibilities.
Instant-payment requirements should therefore identify at least:
- customer-facing provider;
- account-holding financial institution;
- sending participant;
- receiving participant;
- reachable routing endpoint;
- connection or technology provider;
- funding or settlement agent if applicable;
- liquidity-management owner;
- fraud-decision owner;
- sanctions/compliance owner;
- customer-posting owner;
- operations and incident owner;
- reporting and reconciliation owner.
The need for this detail becomes obvious during an outage. If the customer channel works but the connection provider is down, which party detects it? Who stops retries from creating duplicates? Who tells the customer? If the network is available but settlement liquidity is constrained, who decides whether the payment can be released? If the receiving bank is reachable but its posting layer is degraded, what status is returned?
Instant payments are fast only when every participant in the chain performs its role fast enough.
9. Card participants: cardholder, merchant, gateway, acquirer, network and issuer
The card ecosystem contains more visible commercial roles than most account-to-account rails.
The classic model begins with four core parties:
Cardholder → Merchant → Acquirer → Card Network → Issuer → Cardholder
The cardholder uses a card credential or token.
The merchant accepts the payment for goods or services.
The issuer is the financial institution that issued the card or account relationship to the cardholder. It decides whether to authorise the transaction based on account state, funds or credit, fraud controls and scheme rules.
The acquirer provides merchant acquiring services, accepts the merchant’s card transactions into the card system and supports clearing, settlement and merchant funding.
The card network provides the scheme, message routing, rules and interbank framework connecting issuers and acquirers.
Modern commerce adds several participants.
A payment gateway captures transaction data from ecommerce or other digital channels, handles secure transmission and may perform tokenisation or orchestration functions.
A processor may provide issuer processing, acquiring processing or both. It can operate authorisation switching, clearing files, fraud interfaces and settlement support on behalf of financial institutions.
A payment facilitator (PayFac) can onboard and service sub-merchants under its acquiring arrangement, changing who owns merchant onboarding, monitoring and settlement relationships.
An independent sales organisation, software platform, marketplace or orchestration provider may sit between merchant and acquirer.
A token service can replace primary account credentials with network or device tokens.
A digital wallet may present a tokenised credential without becoming the underlying card settlement network.
The merchant may therefore say “we use Apple Pay” while the bank sees a tokenised card transaction flowing through a gateway, acquirer, network and issuer.
For participant mapping, separate acceptance, authorisation, clearing, settlement and merchant funding. The party that captures the payment at checkout is not automatically the party that settles the merchant.
Merchant reconciliation needs participant-level evidence because gross sales, gateway captures, acquirer clearing records, network fees and final bank credits can differ.
If a merchant disputes a funding difference, operations must know whether the issue arose in gateway capture, processor batching, acquirer settlement, network adjustment, reserve handling, chargeback activity or bank posting.
That is why “card processor” should never be a catch-all label in architecture documents.
10. Check and lockbox participants: paper at the edge, institutions in the middle
A check begins with a drawer and payee but quickly becomes an institutional collection process.
The drawer writes the check against an account at the paying bank.
The payee receives the check.
The Bank of First Deposit (BOFD) accepts the check for deposit. This may be the payee’s bank, though collection channels such as lockbox or remote deposit capture can introduce processors before the item reaches the bank’s clearing process.
The paying bank is the institution on which the check is drawn and determines whether the check is paid or returned.
Check clearing can then involve Federal Reserve Check Services, The Clearing House Image Exchange, ECCHO member arrangements, direct exchanges, correspondents and processors.
Federal Reserve Check 21-enabled services allow financial institutions to send and receive image cash letters electronically. The Clearing House Image Exchange provides a peer-to-peer image exchange network for financial institutions. ECCHO rules provide a common rule framework for electronic check exchange among members.
A lockbox processor adds another participant layer. The customer mails a check and remittance stub to a designated address. The lockbox provider collects mail, opens envelopes, images documents, captures remittance data, prepares deposits and provides files to the biller.
A bank may own and operate the lockbox itself or use specialised processing arrangements. Either way, the corporate customer expects a bank product outcome: same-day or contracted deposit handling, images, remittance information, reporting and exception support.
The participant chain may be:
Drawer → Mail service → Lockbox processor → Depositary/BOFD bank → Image exchange or Federal Reserve → Paying bank → Settlement → Corporate account → AR system
That chain explains why a lockbox failure can occur before the check ever reaches interbank clearing. Mail can be delayed. Image quality can fail. Remittance can be keyed incorrectly. A deposit can miss cutoff. The paying bank can return the item. Cash application can fail after the bank has already credited the corporate account.
Each failure belongs to a different participant.
Remote Deposit Capture changes the first part of the chain. The corporate or consumer captures an image, but the depositary institution still owns the deposit relationship and forwards the item into check clearing.
Technology changes the capture participant. It does not eliminate the paying bank, BOFD, clearing arrangements or return responsibilities.
11. Correspondent, respondent, sponsor and intermediary institutions
Indirect access is normal enough in banking that it must be part of the foundation.
A correspondent bank provides banking services to another financial institution. The institution receiving those services is commonly described as the respondent. Services can include account holding, wire execution, cross-border payments, clearing access, liquidity and settlement support.
A sponsor bank is a common term in fintech and platform models for the regulated financial institution providing account, payment or network access capabilities that the non-bank platform cannot perform independently.
An intermediary bank is a bank that sits between the originating and beneficiary institutions in a payment chain, especially in cross-border payments.
These labels can overlap in real commercial arrangements, so requirements should describe the function instead of relying only on the label.
Ask:
- Does the institution hold an account for another bank?
- Does it transmit network messages for the other bank?
- Does it provide settlement through its master account?
- Does it sponsor network access?
- Does it perform compliance controls on its own behalf?
- Does it provide liquidity?
- Does it receive returns or investigations first?
- Does it expose status APIs/files back to the respondent?
- Is the underlying end customer known to it or only the respondent institution?
A fintech “banking” app can be a good example. The app company may own the user interface and customer experience. A partner bank may hold customer funds. Another processor may operate the ledger technology. A card issuer processor may manage card transactions. An ACH provider may generate files. An instant-payments gateway may connect the sponsor bank to the network.
The customer sees one brand. The payment architecture sees many participants.
A strong design therefore maintains a participant-of-record model that identifies legal entity, functional role, network role, settlement role and technical endpoint separately.
This also helps incident management. “Provider X is down” is useful only if the bank knows what function Provider X performs and what payment states depend on it.
12. Fintechs, processors, gateways, PayFacs and platform intermediaries
Non-bank technology participants are now embedded across US payment journeys, but they do not all perform the same function.
A processor performs processing functions for a financial institution, merchant or platform. It may operate card authorisation, ACH file creation, network message transformation, core posting interfaces or settlement reporting.
A gateway is usually a connectivity or capture layer, particularly in ecommerce and card acceptance, but the term is also used more broadly for network connectors such as instant-payment gateways.
A payment service provider (PSP) may combine gateway, acquiring, orchestration, fraud, tokenisation and settlement-reporting capabilities.
A PayFac facilitates merchant acceptance under a broader acquiring relationship and may onboard sub-merchants.
A marketplace connects buyers and sellers and may orchestrate collections, hold funds under an applicable regulated model, calculate splits and trigger payouts through banking partners.
A billing platform can present invoices and initiate card, ACH or account-to-account collections without itself being the bank or network.
A payroll platform can create payment instructions for employers and may act as a service provider or occupy a more formal ACH third-party role depending on the arrangement.
An ERP or treasury workstation can create payment files and receive statuses while the bank remains the executing financial institution.
The key design rule is to classify third parties by function and obligation, not by marketing description.
A product brochure may call a provider “the payment platform.” That tells you almost nothing about whether it is:
- holding accounts;
- creating instructions;
- authenticating users;
- underwriting merchants;
- performing fraud screening;
- acting as an ACH Third-Party Sender;
- transmitting files;
- connecting to a network;
- providing settlement;
- reconciling funds;
- or merely displaying status.
The 2026 Nacha rules make this especially relevant for ACH third parties because certain risk and compliance obligations apply based on role.
Third parties also introduce data ownership questions. Which provider generates the canonical payment ID? Which participant stores customer consent? Who retains audit logs? Who can prove that a retry did not create a duplicate? Who receives network reject reasons? Who has the information needed for a sanctions investigation?
An architecture that uses five providers but cannot answer those questions will be expensive to operate even if the happy path works.
13. Control participants: fraud, sanctions, AML, treasury and operations
Not every important payment participant is a network member.
Inside a bank, specialised control and operations teams participate in the lifecycle by making decisions or creating evidence.
The fraud function evaluates customer behaviour, device data, beneficiary risk, transaction patterns and other signals. In instant payments it may sit directly in the synchronous path because the bank has seconds to decide.
The sanctions screening function evaluates relevant parties and transaction data against applicable sanctions obligations and bank policy. A wire may be technically valid but held for review before release.
The AML monitoring function often operates downstream, analysing patterns across accounts and transactions. It may not decide every individual payment in real time, but its output can influence account restrictions, investigations and future controls.
The treasury or liquidity function manages the bank’s settlement resources. Customer available funds and bank settlement liquidity are different. A customer may have enough money while the institution still needs to manage network prefunding or master-account capacity.
The payment operations team monitors queues, network responses, cutoffs, repairs, returns and incidents.
The customer-service or relationship team translates payment states into customer communication.
The investigations team follows references across institutions and systems when payment status is unclear.
The reconciliation team confirms that network, settlement, ledger and reporting records agree.
The accounting function confirms general-ledger impact.
These internal roles should appear in participant maps because they own decisions that systems alone cannot fully explain.
A payment architecture diagram that contains only Channel → Hub → Network → Core is incomplete for operational design. It shows systems but not responsibility.
A more useful model asks, for every step:
- Who is the system owner?
- Who is the business owner?
- Who can release or stop the payment?
- Who responds to a failed control?
- Who owns 24/7 support?
- Who owns customer communication?
- Who reconciles the event?
- Who has authority to repair data?
- Who can request return or recovery?
- Who retains evidence?
When the payment fails at 2:00 a.m. on Sunday, these ownership questions become more important than the architecture arrows.
14. Settlement, liquidity, accounting, reporting and reconciliation participants
The participant chain does not end when a network accepts a message.
A settlement institution holds or provides the account through which the interbank obligation is discharged.
A settlement agent may submit or facilitate settlement on behalf of participants in a clearing arrangement.
A funding agent can provide the funding relationship required by a payment network.
A liquidity provider supports liquidity movements or capacity that enable payment execution.
For National Settlement Service, a settlement agent submits files on behalf of depository institutions that settle positions for participants in clearing arrangements. This demonstrates an important point: the entity calculating a net position, the settlement agent submitting it and the institutions whose master accounts are posted can be separate participants.
After settlement, the core banking system and account operations post the customer ledger.
The general ledger records the bank’s accounting consequence.
The customer reporting platform produces statements, advices, files or APIs.
The reconciliation engine or team matches payment instructions, network records, settlement positions, ledger postings and customer reporting.
The corporate receivables system may then match a collection to an invoice.
For a merchant, the acquirer’s settlement report may need to reconcile to a bank-account credit and to gateway sales data.
For ACH, batch totals and returns need to reconcile to settlement and customer postings.
For wires and instant payments, item-level references can connect network acceptance to settlement and account posting.
This is why reconciliation participants need stable IDs from upstream systems. If the network reference is discarded when the core posts the transaction, operations loses the ability to prove the end-to-end chain.
A mature participant model therefore includes the evidence producer and evidence consumer at each stage.
The network produces acknowledgements. Settlement services produce positions or confirmations. Core systems produce ledger IDs. Reporting platforms produce customer-visible references. Reconciliation consumes all of them.
The money may move once, but many participants must agree on what happened.
15. Four participant stories: how the chain changes by payment type
Participant theory becomes useful when you can apply it to real business events.
Story A — corporate ACH debit collection through a Third-Party Sender
A property-management company wants to collect monthly rent from thousands of authorised tenants.
The property platform manages tenant onboarding and billing. It has a relationship with a Third-Party Sender. The Third-Party Sender transmits entries through its ODFI. The ACH Operator distributes entries to tenant RDFIs. Tenant accounts are debited and the property company receives settlement and reporting through its banking arrangement.
The visible business chain is “tenant → property company.”
The operational chain is more like:
Tenant/Receiver → RDFI ↔ ACH Operator ↔ ODFI → Third-Party Sender → Property company/Originator
The direction is easier to understand from the Originator’s perspective: Property company → TPS → ODFI → Operator → RDFI → tenant Receiver account.
Now consider a return. The RDFI creates the return under the applicable ACH process. It travels back through the operator and ODFI. The Third-Party Sender and property platform need enough information to reopen the receivable and communicate with the tenant.
If the platform does not know its formal role or who owns return processing, the collection product breaks operationally even though origination works.
Story B — $8 million supplier payment using correspondent access
A regional bank’s corporate customer needs to send an $8 million payment to a supplier.
The corporate authenticates to its bank. The bank performs approvals, funds checks, fraud and compliance controls. The regional bank uses a correspondent for the required high-value network access. The correspondent transmits the payment. The receiving bank credits the supplier.
The corporate has no direct relationship with the correspondent, but the correspondent becomes critical to execution.
The customer-facing bank must therefore preserve a mapping between its own payment ID and the correspondent/network references.
If the supplier says funds were not received, the customer should not be told simply “the correspondent has it.” The bank needs a controlled investigation path and evidence.
Story C — ecommerce card sale through a PayFac
A small online merchant accepts a $250 purchase.
The merchant uses a commerce platform acting through a PayFac model. The platform provides checkout and gateway capability. An acquiring relationship connects the transaction to the card network. The issuer authorises the cardholder. Later, clearing and settlement occur and the merchant receives net funding after applicable fees and adjustments.
The customer sees merchant + wallet/card.
The merchant sees platform + payout.
The payment chain contains cardholder, merchant, PayFac/platform, gateway/processor, acquirer, network, issuer and settlement/funding processes.
A chargeback later introduces dispute participants and evidence requirements that are completely different from an ACH return.
Story D — Request for Payment followed by instant credit push
A utility sends a Request for Payment to a customer. The customer reviews the bill inside its banking channel and approves.
The utility is the request initiator, but the customer becomes the payer authorising the actual credit transfer. The sending bank validates and routes the instant payment. The receiving bank posts the utility’s account.
Depending on the selected network and institutional model, technology providers, funding agents or settlement agents may support the banks.
The participant lesson is subtle but important:
the party asking for money is not automatically the party initiating the funds movement.
That distinction affects fraud, consent, customer messaging and exception handling.
16. The practitioner participant map: requirements, testing and ownership
A Chapter 2 participant model is complete only when it can be used in delivery.
Start every payment requirement with a participant table containing these columns:
Participant | Legal entity | Business role | Network role | Account role | Settlement role | Technical endpoint | Control responsibility | Reporting responsibility | Exception owner
For a simple on-us transfer, several columns may point to the same bank.
For an ACH transaction through a Third-Party Sender, the roles split.
For a cross-border wire, multiple banks may appear.
For a card merchant payment, merchant, gateway, processor, PayFac, acquirer, network and issuer may all appear.
For an instant payment, account-holding institution, network participant, connection provider and settlement/funding role may need separate rows.
Then ask a second set of questions.
Authority
Who is authorised to create the instruction? Who approves it? Who can amend it? Who can release it?
Account ownership
Who holds the payer account? Who holds the payee account? Which institution owns the contractual product relationship?
Network access
Which entity is the direct participant? If access is indirect, through whom? Which routing or participant identifier proves reachability?
Settlement
Whose account settles? Is a settlement agent, funding agent or correspondent involved? Who manages liquidity?
Controls
Who performs customer authentication? Fraud decisioning? Sanctions screening? ACH or merchant underwriting? Limit control?
Data
Which participant creates the canonical transaction ID? Which identifiers must survive handoffs? Who owns remittance integrity?
Status
Who receives the first network acknowledgement? How does it reach the customer-facing institution? Which participant can declare settlement complete?
Exceptions
Who receives a reject or return? Who repairs invalid data? Who requests recovery? Who owns disputes? Who talks to the customer?
Reconciliation
Who proves the participant chain end to end? Which settlement, ledger and reporting records must match?
Resilience
What happens when a processor, correspondent, funding agent, network, core or reporting platform is unavailable? Is there an approved fallback or must the product stop?
Testing should then validate participant boundaries, not only payment values.
A good Chapter 2 test pack includes:
- direct participant happy path;
- indirect/correspondent path;
- sender reachable but receiver not reachable;
- technology provider unavailable;
- settlement agent or funding path unavailable;
- wrong participant routing identifier;
- customer bank succeeds but correspondent rejects;
- network accepts but receiving bank cannot post;
- duplicate created at an intermediary retry boundary;
- third-party ACH return routed to the wrong Originator;
- merchant funding mismatch between acquirer and bank credit;
- check return sent to the wrong BOFD endpoint;
- missing network reference in customer reporting;
- reconciliation break between processor and bank ledger;
- outage where responsibility is unclear.
If the team cannot say who owns each of those failures, the participant model is incomplete.
Build a participant RACI, not only a flow diagram
A flow diagram tells you that a message moves from one box to another. A participant RACI tells you who is responsible, accountable, consulted and informed when that movement succeeds or fails.
For example, suppose a corporate file is submitted through a treasury channel and routed to an ACH processor. The channel team may be responsible for capture. The payments product team may be accountable for product behaviour. The fraud team may be responsible for a risk decision. The ODFI remains accountable for its network obligations. A service provider may be responsible for file transmission. Operations may be responsible for repairing rejected entries. Reconciliation may be responsible for proving that settlement and postings match.
Without a RACI, every system can be “green” while the customer still has no owner for the problem.
The participant RACI should cover at least initiation, authentication, authorisation, validation, fraud, sanctions, routing, network connectivity, settlement, liquidity, posting, reporting, reconciliation, exceptions, investigation and customer communication.
Do not assign all of these to “Payments Operations.” That hides genuine ownership boundaries. In a 24/7 payment product, the team that detects an outage, the team that can stop transaction release and the team that communicates externally may be three different teams.
Participant identifiers are part of the functional design
Every participant needs an identifier that other systems can use consistently.
A corporate Originator can have a customer ID, company ID and bank-specific relationship ID. An ODFI and RDFI are identified through routing information in ACH records. Fedwire and instant-payment reachability depend on routing endpoints and service participation. CHIPS participants have their own network identifiers. Card participants use issuer/acquirer and network identifiers. Check processing uses routing information, endorsements and image-cash-letter data. A correspondent chain can introduce BICs, routing numbers, account references and internal relationship IDs.
The functional model should say which identifier is authoritative for each purpose.
A routing number identifies an institution in a particular context; it does not prove every service capability. A BIC identifies an institution for messaging but does not prove that the institution is a direct participant in the settlement rail. A card BIN/IIN identifies issuer-related information but does not identify the merchant acquirer. A customer ID identifies the bank relationship but not the beneficiary account.
When systems substitute one identifier for another, routing mistakes and investigation problems follow.
A strong participant record therefore stores role, legal entity, network identifier, routing identifier, technical endpoint, account relationship and effective dates rather than one free-text “Bank Name” field.
Participant onboarding is a control process
Before a participant becomes active, somebody has to decide that the relationship is allowed.
For an ACH Originator, the ODFI may perform underwriting and risk assessment before permitting origination. For a Third-Party Sender, the ODFI needs to understand the sender’s business model and downstream relationships. For merchant acquiring, the acquirer or PayFac performs merchant onboarding and risk assessment. For correspondent banking, institutions perform due diligence on the respondent relationship. For network participation, financial institutions complete service setup, technical certification and legal agreements. For a fintech sponsor relationship, the regulated bank evaluates the programme, controls and operational model.
Participant onboarding should therefore have states such as proposed, due-diligence pending, approved, technically certified, enabled for receive, enabled for send, suspended and terminated.
This state affects payment execution. A participant can be technically configured but not commercially authorised. A merchant can have a gateway account but be suspended from settlement. An ACH Originator can have a valid file format but be blocked by the ODFI. A routing number can exist while the instant-payment capability is not enabled.
Product systems need to distinguish configuration from permission.
Participant capability changes over time
Participation is not static.
A bank can add a new rail, change from receive-only to send-and-receive, change its service provider, add a funding agent, alter a correspondent arrangement or retire a routing endpoint. A merchant can move acquirers. An ACH customer can change Third-Party Sender. A fintech can migrate sponsor banks. A check processor can change an image-exchange route.
That means participant capability needs effective dating and change control.
If the bank caches a participant directory indefinitely, a payment can be routed using stale information. If a sponsor-bank migration is not reflected consistently across customer accounts, routing, reporting and reconciliation, one customer transaction can be split across old and new participant chains.
A mature implementation therefore treats participant data as controlled reference data with ownership, update frequency, validation, version history and audit.
Direct versus indirect access changes operational evidence
Direct access usually gives the institution first-hand network status and settlement information. Indirect access inserts another participant between the customer-facing bank and the network.
That difference affects evidence.
A direct participant may receive the network acknowledgement itself. An indirect institution may receive a translated status from its correspondent or provider. The direct participant may see the original reject code. The indirect institution may receive a mapped code. The direct participant may reconcile directly to a settlement account. The indirect institution may reconcile first to a correspondent statement and only indirectly to the network.
Neither model is automatically better. The design must simply recognise the additional boundary.
For investigations, ask whether the customer-facing bank has access to the original network reference, original timestamps, original reason codes and settlement evidence. If not, define how they are obtained and what service level applies.
The participant that moves the message may not move the money
This is one of the most important distinctions in payments.
A service bureau can transmit an ACH file while settlement occurs between financial institutions. SWIFT can transmit a cross-border message while USD settlement happens through Fedwire, CHIPS or correspondent accounts. A gateway can transmit a card authorisation while issuer/acquirer obligations settle later. A core vendor can transmit a FedNow message while the participating financial institution’s settlement relationship is used.
Therefore architecture documentation should use different verbs:
- captures the instruction;
- transmits the message;
- clears the obligation;
- settles the obligation;
- posts the customer account;
- reports the outcome.
Avoid drawing an arrow labelled “moves funds” from every provider.
The participant that holds customer funds matters
When platforms and fintechs are involved, identify the institution that actually holds the customer’s deposit or stored value and the legal structure under which it does so.
A user can interact entirely with a fintech brand while the underlying account is at a partner bank. A marketplace can display a balance while funds are held in custodial or programme accounts at a bank. A merchant can see a PayFac dashboard while settlement funds move through an acquiring and banking relationship.
This matters for account statements, deposit insurance disclosures where applicable, error handling, sanctions controls, legal orders, reconciliation and insolvency risk.
The chapter does not need to teach every fintech legal structure, but a BA must never assume that the company showing a balance on screen is the institution holding the legal deposit account.
Regulatory and governance bodies are ecosystem participants, but not transaction hops
Regulators and rulemaking bodies influence participant behaviour even though they do not sit in the message path for every payment.
Nacha administers ACH rules. The Federal Reserve operates services and also has regulatory responsibilities through the Board and Reserve Banks in their respective capacities. The Clearing House operates private payment systems. Card networks maintain scheme rules. Federal and state regulators supervise financial institutions according to charter and activity. The CFPB has consumer-protection responsibilities. OFAC administers US economic sanctions.
These entities are not all “payment processors.” Their role is governance, operation, supervision or rulemaking.
This distinction matters in documentation. A diagram can show governance as an outer layer rather than putting a regulator between payer and payee.
Participant responsibility survives outsourcing
A recurring design mistake is to write: “Vendor performs fraud, therefore bank has no fraud responsibility,” or “processor handles ACH, therefore the ODFI does not need to know the Originator.”
Outsourcing can transfer performance of an activity. It does not automatically transfer every legal, network or contractual responsibility.
The bank therefore needs oversight of the provider, service-level obligations, incident notification, audit rights, resilience planning, data controls and clear exit/migration arrangements.
A processor failure is still a bank customer problem when the processor is part of the bank’s product.
Participant concentration risk belongs in payment design
If one provider supports many rails, a single outage can become a cross-rail incident.
A bank may use one core vendor for ACH, RTP and FedNow connectivity. One cloud or network provider may support several payment gateways. One correspondent may provide access to multiple high-value services. One processor may support thousands of merchants.
Participant maps should therefore identify shared dependencies.
A good resilience review asks:
- Which participants are single points of failure?
- Which participants support more than one rail?
- Which have tested contingency paths?
- Which can be bypassed under an approved continuity plan?
- Which require manual procedures?
- Which participant failure would prevent customer reporting even if settlement still works?
This is not infrastructure trivia. It determines whether the bank can keep its payment promise.
Participant-level service levels
An end-to-end SLA is only achievable if critical participants have compatible service levels.
Suppose the bank promises an instant payment response in ten seconds. The fraud provider cannot have a thirty-second timeout. The connection gateway cannot retry for a minute. The core cannot post only in batch. The settlement capacity cannot be monitored only during business hours.
For a same-day wire, customer cutoff, compliance review, correspondent cutoff and network hours all need alignment.
For lockbox, mail sweep time, image capture cutoff, deposit deadline and remittance-file delivery all contribute to the corporate SLA.
Participant-level SLAs should therefore roll up into the customer service promise.
Participant data and privacy boundaries
Payment chains exchange sensitive data. Each participant should receive the data it genuinely needs for its role.
A fraud provider may need transaction and device information. A network needs payment-message data. A correspondent needs sufficient originator and beneficiary information. A processor needs operational fields. A reconciliation service needs identifiers and financial amounts.
Sending every data element to every provider creates unnecessary exposure and complexity.
The participant model should identify data controller/owner where relevant, permitted use, retention, security classification and onward-sharing constraints according to the bank’s legal and security framework.
For ISO 20022 and richer payment data, this becomes increasingly important because the message can contain more structured party and remittance information than legacy systems carried.
Participant offboarding is as important as onboarding
When a provider or participant relationship ends, the bank must remove access safely without destroying evidence.
Offboarding may require disabling credentials, removing network endpoints, changing routing, migrating customer configurations, preserving historical records, redirecting reports, settling outstanding positions and ensuring returns or late exceptions still reach an owner.
A Third-Party Sender relationship can end while ACH returns still arrive later. A merchant can change acquirers while old chargebacks remain open. A correspondent relationship can close while investigations on historical payments are unresolved.
The participant lifecycle therefore extends beyond the last successful transaction.
A reusable participant responsibility matrix
For every participant, record the following:
- Role name — e.g. ODFI, RDFI, issuer, acquirer, correspondent, settlement agent.
- Legal entity — the organisation actually accountable.
- Customer relationship — whose customer is it?
- Account relationship — which accounts does it hold?
- Network relationship — direct participant, indirect participant, provider or non-participant.
- Technical function — capture, transform, transmit, process, store or report.
- Settlement function — own account, agent, correspondent or none.
- Control function — authentication, fraud, sanctions, limits, underwriting or none.
- Data responsibility — what data it creates and preserves.
- Status responsibility — what acknowledgements or states it generates.
- Exception responsibility — reject, return, dispute, investigation or recovery owner.
- Reconciliation responsibility — what records it proves.
- Support window — business hours or 24/7.
- Contingency — fallback or no-fallback.
- Evidence retention — what must remain available after the transaction.
This matrix turns Chapter 2 knowledge into a practical delivery artefact.
Participant mapping by collection channel
Collections are especially participant-heavy because the organisation receiving money often does not control the payer’s initiation channel.
For ACH debit, the biller or its authorised intermediary originates the debit. The ODFI sponsors the origination into ACH. The ACH Operator routes the entry. The RDFI applies the debit to the Receiver’s account. Returns then travel back through that participant chain. The biller’s accounts-receivable team is a downstream participant because it decides whether a returned collection reopens the invoice, triggers customer contact or generates a retry.
For ACH credit, the payer initiates through its own bank. The biller may not know in advance exactly when the payment will arrive. Remittance data becomes critical because the receiving bank and corporate cash-application system must identify the receivable after the payer-controlled transaction arrives.
For Request for Payment, the biller or biller service creates the request, but the payer’s bank owns the actual payment authorisation. The receiving bank posts the approved credit. A request provider, directory or messaging participant may be involved without ever debiting the payer’s account itself.
For lockbox, the biller outsources physical and data-processing work. Mail carriers, lockbox processors, depositary banks, image exchange services and paying banks all participate before the corporate ERP sees the cash. A lockbox SLA therefore depends on non-payment participants such as mail operations and document capture as well as on the check-clearing chain.
For card collections, merchant, gateway, PayFac, acquirer, processor, network and issuer all contribute to the transaction. Merchant funding is then a further relationship between the merchant and its acquirer or provider. The merchant’s bank account may sit at yet another institution.
For cash collection, store staff, smart-safe provider, cash-in-transit carrier, vault, account-holding bank and reconciliation platform may all participate. No electronic clearing rail is needed for the physical collection itself, but several parties still create settlement-like and evidence responsibilities.
The collection lesson is that the receiver’s bank is only one participant in the receivables process. The business outcome is complete only when the corporate can identify, apply and reconcile the receipt.
Participant failure ownership: eight examples
Example 1 — invalid ACH routing data. The Originator or service provider may have supplied bad information. The ODFI should detect what it can before release. If the entry reaches the RDFI and is returned, operations must route that return to the correct Originator. The failure cannot remain labelled only “ACH failed.”
Example 2 — FedNow receiving endpoint not reachable. The sending bank owns the customer decision. It may offer another permitted route, reject the request or ask the customer to choose. The network directory or reachability service provides information, but it does not own the customer promise.
Example 3 — correspondent rejects a wire. The customer-facing bank owns investigation and communication even if the correspondent produced the reject. The original reason code and reference should flow back across the relationship.
Example 4 — card gateway approves capture but acquirer does not fund expected amount. The merchant needs to distinguish gateway transaction success from clearing and funding. Reconciliation must identify whether the difference is fee, reserve, refund, chargeback, adjustment or missing settlement.
Example 5 — lockbox image captured but remittance data missing. The check may still clear and the corporate account may be credited. The financial collection succeeds while the receivables process fails. Lockbox operations or data-capture ownership becomes the exception owner, not the paying bank.
Example 6 — instant-payment connection provider times out after network acceptance. The bank must not blindly resend. The participant model must identify who can query final status, what idempotency identifier exists and who can reconcile a payment whose customer channel timed out.
Example 7 — receiving bank posts twice after duplicate internal event handling. The external network may have processed only one payment. The receiving institution owns the duplicate ledger problem even though the customer may initially blame the network.
Example 8 — reconciliation file arrives late. The payment can be financially complete while operational proof is delayed. The reporting provider, network file process or internal data platform may own the delay. Finance and operations need a controlled temporary state rather than manually assuming a break.
These examples show why participant ownership must be tied to events, not to generic systems.
Participant modelling in APIs and event-driven architecture
Modern banks often represent a payment as events distributed over APIs and messaging platforms. Participant design still matters.
An API request should identify the instructing customer, account-holding institution, debtor/creditor or payer/payee role, routing endpoint and any intermediary required for execution. An event should identify the participant that produced the state change.
For example, PAYMENT_ACCEPTED is ambiguous unless you know accepted by whom. It could mean the customer channel accepted the request, the payment hub validated it, the network accepted it, the receiving bank accepted it or the beneficiary account was posted.
Better event models use participant-aware states such as:
- customer instruction captured;
- bank validation completed;
- network submitted;
- network accepted;
- receiving participant accepted;
- settlement completed;
- beneficiary posted;
- customer notified.
The same principle applies to error events. PAYMENT_REJECTED should carry rejecting participant, stage, reason, timestamp and retryability.
Participant IDs also support distributed tracing. A trace can show that one payment passed from customer channel to orchestration, service provider, network gateway, external network, receiving bank and ledger. Operations can then identify the exact boundary where expected evidence stopped.
This is especially useful when several providers are involved and each uses its own reference.
What Chapter 2 intentionally does not cover
Depth does not mean stealing the content of later chapters.
This chapter does not teach detailed ACH SEC codes, ACH return-code catalogues, Fedwire ISO 20022 field mappings, CHIPS liquidity algorithms, RTP and FedNow message flows, card interchange calculations, chargeback reason codes, Check 21 warranties, or detailed regulatory obligations. Those have dedicated homes later in the USA programme.
Chapter 2 gives the participant framework required to understand those later details correctly.
When Chapter 3 discusses push, pull, Request for Payment and on-us transfers, you should already know who can initiate, who owns the account, who executes, who settles and who reports.
When the ACH branches begin, ODFI, RDFI, Originator, Receiver and third-party roles should already be familiar.
When high-value and instant chapters begin, direct versus indirect access, correspondents, funding agents, settlement agents and technology providers should already make sense.
When card and check chapters begin, issuer/acquirer and BOFD/paying-bank roles should already be clear.
That is the purpose of this chapter: give every later payment flow a precise cast of participants before we go deeper into the mechanics.
The participant test: can the team answer five ownership questions?
Before approving any flow, take each external and internal participant and ask five questions.
What does this participant receive? It may receive a customer instruction, file, API request, network message, settlement position, check image, card authorisation, return, statement or exception case.
What decision can this participant make? It may approve, reject, route, hold, settle, post, return, dispute, repair or only transmit. A processor that cannot legally release a payment should not be modelled as the decision maker simply because its software sends the message.
What evidence does this participant create? Examples include an authentication record, approval timestamp, network acknowledgement, settlement reference, ledger booking ID, return reason, chargeback record or reconciliation result.
What happens if this participant is unavailable? The answer may be queue, reject, use a tested contingency route, switch provider, operate manually or stop the service. “Retry until it works” is not a resilience design.
Who remains accountable to the customer? This is the most important question. A bank can use a processor, correspondent or technology provider, but the customer normally deals with the institution or provider that sold the service. That customer-facing participant needs enough visibility to explain what happened.
If a team can answer these five questions for every participant, architecture, testing and operational ownership become much clearer. If the team cannot, the flow is not ready for production even if the technical sequence looks complete.
One final distinction: participant, provider and operator
These three words should not be used interchangeably.
A participant has a defined role in a payment arrangement or network and is subject to the responsibilities attached to that role. A provider performs a service for another party, such as connectivity, processing, gateway, fraud, reporting or technology support. An operator runs the payment or clearing infrastructure itself.
One organisation can occupy more than one of these categories, but the categories describe different responsibilities. The Federal Reserve Banks operate Fedwire and FedNow. A financial institution participates in those services. A certified technology company may provide connectivity. The Clearing House operates RTP and CHIPS. Banks participate; technology firms may support connection or processing.
Using the correct word prevents a common architecture error: assuming that the company hosting the technical connection is the institution that owns settlement, network obligations or the customer relationship.
Participant checkpoint
Before moving to Chapter 3, you should be able to answer these questions without looking back:
- Why are payer/payee roles different from formal ACH Originator/Receiver roles?
- What makes an ODFI different from an ACH Operator?
- What does an RDFI own?
- What is the difference between a TPSP and a Third-Party Sender?
- Why does a Nested Third-Party Sender create additional responsibility?
- How can a financial institution access Federal Reserve services without using its own master account for settlement?
- Why are FedNow participant, settlement-agent, liquidity-provider and service-provider roles separate?
- How can a bank offer CHIPS capability without being one of the direct CHIPS participant banks?
- Why is “the bank is on RTP” an incomplete requirement?
- What is the difference between a card issuer, acquirer, processor, gateway and network?
- What is the role of the Bank of First Deposit in check clearing?
- Why is a lockbox processor not the same as the paying bank?
- What does a correspondent bank do for a respondent institution?
- Why can a fintech own the customer experience without being the settlement institution?
- Which internal bank participants matter even though they are not network members?
- Why must payment IDs survive across processors, correspondents and networks?
- What participant information is required for end-to-end reconciliation?
- Who owns the customer problem when a third-party provider fails?
If you can explain those answers in your own words, you understand the participant structure well enough to go deeper into push, pull, Request for Payment and on-us transfers in Chapter 3.
Official and primary references
This chapter uses the supplied USA Collections, Payments & Clearing Workbook as its curriculum baseline, especially its Banking Architecture, Flow Diagrams and Clearing & Settlement sheets, and validates participant definitions and current access structures against primary sources.
Nacha — How ACH Works / participant definitions
https://achdevguide.nacha.org/index.php/how-ach-works
Nacha — Third Parties in the ACH Network
https://www.nacha.org/content/third-parties-ach-network
Nacha — 2026 fraud monitoring / participant responsibilities
https://www.nacha.org/rules/risk-management-topics-fraud-monitoring-phase-1
https://www.nacha.org/rules/risk-management-topics-fraud-monitoring-phase-2
Federal Reserve Financial Services — Fedwire Funds Service
https://www.frbservices.org/financial-services/wires/
Federal Reserve Board — Master Account and Services Database
https://www.federalreserve.gov/paymentsystems/master-account-and-services-database-about.htm
Federal Reserve Financial Services — FedNow participants and service providers
https://www.frbservices.org/financial-services/fednow/organizations/
Federal Reserve Financial Services — National Settlement Service
https://www.frbservices.org/financial-services/national-settlement-service/
The Clearing House — CHIPS
https://www.theclearinghouse.org/payment-systems/chips
The Clearing House — CHIPS resources and participant information
https://www.theclearinghouse.org/payment-systems/CHIPS/CHIPS-Resources
The Clearing House — RTP document library, participants, funding and technology providers
https://www.theclearinghouse.org/payment-systems/rtp/document-library
Federal Reserve Financial Services — Check Services
https://www.frbservices.org/financial-services/check/
Federal Reserve Financial Services — Check 21-enabled image services
https://www.frbservices.org/financial-services/check/check21.html
The Clearing House — Image Exchange
https://www.theclearinghouse.org/payment-systems/image-exchange
The Clearing House — ECCHO membership and electronic check exchange rules
https://www.theclearinghouse.org/ECCHO/ECCHO-Membership
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.