European Payments & Collections Overview

1. Why this chapter matters

European payments and collections are not one country, one currency, one rail, one scheme, one rulebook or one message format.

They are a layered operating ecosystem.

A customer may see only a payment button, a salary file, a bill collection, a card tap, a QR checkout, an account-to-account approval or a statement entry. Behind that simple customer moment, a bank may have to handle authentication, authority, account checks, entitlement, data validation, fraud controls, sanctions screening, Verification of Payee, mandate rules, scheme selection, participant reachability, routing, clearing, settlement, liquidity, booking, exceptions, customer reporting and reconciliation.

That is why this overview starts with the whole operating model instead of one acronym.

SEPA is a major part of European payments, but SEPA is not the whole of Europe. Europe also contains domestic non-euro payment systems, local clearing arrangements, card ecosystems, merchant acquiring, open banking payment initiation, request-to-pay services, high-value euro settlement, central-bank-money infrastructures, non-euro currencies, local bill-payment habits, public-sector payments, treasury flows and cross-border links.

ISO 20022 is also important, but the message is not the payment. A message carries structured business data. It does not by itself decide the customer product, legal boundary, participant responsibility, settlement route, refund right, investigation process or reconciliation evidence.

The correct way to understand Europe is to ask practical banking questions:

• What is the customer or business trying to do?
• Is the need to pay, collect, request, refund, return, settle, report or reconcile?
• Which country, currency and legal boundary are involved?
• Who are the payer, debtor, payee, creditor, merchant, PSP and infrastructure roles?
• Which product, scheme or domestic rail applies?
• Which message or API carries the instruction?
• Which infrastructure clears or settles it?
• What can go wrong?
• What will the customer see?
• What evidence proves the final outcome?

That is the foundation for the rest of the European Payments & Collections journey.

Learning lens: A payment normally starts from the payer-side need to move money. A collection normally starts from the payee, creditor, biller or merchant-side need to obtain money that is due. Both move value, but they begin from different business intentions and create different controls.

This ecosystem diagram is the starting map. It shows that European payments and collections are not one rail. They are a connected operating model.

2. The simple story before the acronyms

Imagine three ordinary European money moments.

A person in Spain sends EUR to a friend in France.

A Swedish company pays a domestic supplier in SEK.

A German utility company collects monthly electricity bills from thousands of customers.

All three are European payment or collection stories, but they are not the same story.

The Spanish-to-French euro transfer may use SEPA Credit Transfer or SEPA Instant Credit Transfer, depending on the product, reachability and bank capability.

The Swedish SEK supplier payment may use a Swedish domestic payment system, not a SEPA euro scheme.

The German utility collection may use SEPA Direct Debit Core, where creditor onboarding, mandates, requested collection dates, returns and refund rights matter.

If we say only "European payment", we lose the important detail. A professional must identify the exact business flow.

Europe is therefore best understood as a map of layers:

• Geography and law.
• Currency.
• Customer need.
• Participant roles.
• Product or instrument.
• Scheme or domestic rail.
• Infrastructure.
• Message and data.
• Settlement and liquidity.
• Reporting and reconciliation.
• Exception and customer protection.

This is the frame that prevents acronym overload.

3. How to use this chapter

This chapter is the common frame for the Europe Payments & Collections module.

It deliberately stays at ecosystem level first. Later chapters go deeper into history, market structure, boundaries, participants, banks and payment institutions, central banks, clearing and settlement, domestic systems and SEPA.

Use this chapter as the operating map.

A business analyst can use it to ask better discovery questions.

A developer can use it to understand why one customer screen may create different backend journeys.

A tester can use it to design scenarios beyond happy-path execution.

An operations analyst can use it to understand why rejects, returns, refunds, recalls, disputes and reconciliation breaks are not the same thing.

A product owner can use it to define market scope before promising features.

A trainer can use it to explain the full story without forcing learners to memorise acronyms before they understand the business.

Some facts in European payments change over time. Scheme rulebooks are updated. Countries can be added to the SEPA scheme geographical scope. Participant adherence changes. Instant payment obligations evolve. Verification of Payee requirements evolve. TARGET Services releases change. Domestic infrastructures modernise. Regulation moves through EU processes.

For production design, always check the latest official source, relevant bank policy and customer contract.

4. What this overview helps you understand

After this chapter, the learner should be able to explain:

• Why European payments are broader than SEPA.
• Why collections deserve separate treatment from payments.
• Why Europe, EU, EEA, Eurozone and SEPA are different maps.
• Why a euro payment is not automatically the same as one product.
• Why non-euro domestic systems still matter.
• Why cards are not credit transfers.
• Why open banking initiation is not a settlement rail.
• Why Request-to-Pay is not the payment itself.
• Why ISO 20022 messages carry data but do not replace business rules.
• Why reporting and reconciliation are part of the product.

The chapter also separates five ideas that are often mixed.

5. What European payments mean

A European payment is a movement of value within, across or connected to the European payment landscape.

It may be:

• A person sending money to a friend.
• A company paying a supplier.
• An employer paying salaries.
• A public authority paying benefits.
• A customer paying a merchant.
• A bank moving liquidity.
• A treasury team settling a high-value obligation.
• A platform initiating an account-to-account payment with customer consent.

The payment may be euro or non-euro. It may be domestic or cross-border. It may be instant, same-day, next-day, batch, high-value or card-based. It may be account-to-account, card-funded, wallet-supported, treasury-driven, merchant-driven or bank-to-bank.

A complete payment view includes:

• Business reason to pay.
• Payer authority.
• Debtor account.
• Payee details.
• Payer PSP and payee PSP.
• Product and scheme.
• Currency and amount.
• Fraud and sanctions controls.
• Routing and reachability.
• Clearing and settlement.
• Booking.
• Customer reporting.
• Reconciliation.

The word payment is therefore a family name. The analysis begins when we ask which kind of payment.

6. What European collections mean

A European collection is the payee-side, creditor-side, biller-side or merchant-side process of requesting, collecting, receiving, matching or reconciling money owed.

Collections can include:

• SEPA Direct Debit Core.
• SEPA Direct Debit Business-to-Business.
• Local direct debit systems.
• Card acquiring and merchant settlement.
• Invoice-based bank transfers.
• Request-to-Pay.
• Open banking payment initiation.
• Recurring subscriptions.
• Tax and public-sector collection.
• Utility, telecom and insurance collections.
• Cash application and receivables matching.

Collections are not simply payments in reverse.

In a payer-initiated credit transfer, the payer decides to send money. In many collection models, the creditor, biller or merchant starts the process or request. That creates different questions:

• What authority exists?
• Is there a mandate?
• Who is the creditor?
• Who is the debtor?
• What due date applies?
• What refund or return rights apply?
• What reason code must be reported?
• How will the collector match the money to the receivable?

A utility company, insurer, telecom provider, subscription business or tax authority does not simply need a bank balance increase. It needs to know which customer paid, which invoice closed, which mandate failed, which return reason applies, which refund was requested and what remains outstanding.

That is why collections are deeply connected to receivables management, cash application and reporting.

This diagram shows the foundation difference. Payments and collections both involve money, but they start from different business needs and create different controls.

7. Payments and collections comparison

The comparison matters because many projects use one generic word: transaction.

That word is useful only at the highest level. In design, a transaction can be a payment, collection, card authorisation, settlement entry, return, refund, reversal, chargeback, request, notification or statement entry. Without business meaning, the word transaction is too weak.

8. Boundary discipline: Europe, EU, EEA, Eurozone and SEPA

European payment analysis requires boundary discipline.

Europe, the European Union, the European Economic Area, the Eurozone and SEPA are not the same thing.

They overlap, but they answer different questions.

The EPC states that the SEPA scheme geographical scope is broader than the EU. As of the current EPC SEPA information checked for this chapter, the SEPA scheme geography covers 41 countries and territories, including the 27 EU Member States and additional countries and territories such as the United Kingdom, Iceland, Norway, Liechtenstein, Switzerland, Monaco, San Marino, Andorra, Vatican City State/Holy See, Montenegro, Albania, North Macedonia, Moldova and Serbia.

But geographical scope is not the same as operational reachability.

A country can be in SEPA scope, while a specific PSP may still need to adhere to a specific scheme and become operationally reachable. A bank must check country, currency, product, scheme, participant status and reachability.

The practical rule is simple: never ask only whether a payment is European. Ask country, currency, scheme, participant reachability, product, infrastructure, customer type, legal boundary and reporting requirement.

9. SEPA as a major but incomplete layer

SEPA is one of the most important harmonisation layers in European payments.

The core EPC SEPA scheme family includes:

• SEPA Credit Transfer, SCT.
• SEPA Instant Credit Transfer, SCT Inst.
• SEPA Direct Debit Core, SDD Core.
• SEPA Direct Debit Business-to-Business, SDD B2B.

Related EPC schemes and services also support areas such as Verification of Payee, SEPA Request-to-Pay and One-Leg Out Instant Credit Transfer.

SEPA helps customers, businesses and public bodies use common euro account-to-account payment and collection schemes across the SEPA geography.

But SEPA does not replace everything.

It does not replace every domestic system. It does not cover every European currency. It does not replace cards, merchant acquiring, high-value settlement, open banking consent, domestic bill methods or local reporting practices. It does not mean every PSP participates in every scheme. It does not remove the need for reachability checks, mandates, operating windows, exception handling and reconciliation.

The beginner mistake is to say "SEPA payment" without naming the scheme.

The professional question is: which SEPA scheme, which PSPs, which account, which currency, which infrastructure, which status, which exception path and which report?

10. Infrastructures: TARGET Services, EBA CLEARING and domestic systems

Infrastructures are market services that support exchange, clearing and settlement. They are not customer products, and they are not the same as scheme rulebooks.

TARGET Services are developed and operated by the Eurosystem. They include:

• T2 for settling payments in central bank money.
• T2S for securities settlement.
• TIPS for settling instant payments.
• ECMS for collateral management.

The ECB describes TARGET Services as services that ensure the free flow of cash, securities and collateral across Europe. TIPS enables real-time, around-the-clock instant payment settlement. ECMS went live in 2025 and completed the TARGET Services suite.

EBA CLEARING is a pan-European infrastructure provider. Its services include EURO1, STEP2 and RT1. STEP2 supports pan-European mass payment processing, RT1 supports real-time euro payments and EURO1 supports large-value euro payments. EBA CLEARING is not the European Banking Authority.

Domestic systems still matter. Sweden, Denmark, Norway, the United Kingdom, Switzerland, Poland and many other markets have domestic currencies, local infrastructures and local payment habits. Even Eurozone countries can have local practices around bill payments, public-sector payments, cards, reporting, direct debit usage and customer expectations.

The infrastructure question is: where does the obligation move, where is it cleared, and where does settlement become final?

11. Participants in the ecosystem

European payments and collections are role-driven.

The same organisation can perform different roles in different flows. A bank can be debtor PSP in one transaction, creditor PSP in another, issuer in a card flow, acquirer in a merchant flow, direct participant in one infrastructure and indirect participant in another.

The role matters more than the brand name.

Participant roles define responsibility. Responsibility determines data, controls, statuses, exception ownership and customer communication.

12. The lifecycle of a payment

A payment lifecycle begins with a business need: someone needs to send money.

The need may come from a consumer transfer, supplier invoice, payroll file, tax payment, treasury movement, refund, merchant checkout or platform transaction.

A simplified lifecycle is:

1. Customer intent.
2. Authentication and authorisation.
3. Account and entitlement checks.
4. Data validation and enrichment.
5. Fraud, sanctions, AML and limit controls.
6. Product, scheme and route selection.
7. Message or API generation.
8. Exchange, clearing or settlement.
9. Customer account booking.
10. Status, notification and statement reporting.
11. Reconciliation and closure.
12. Exception handling if anything breaks.

A payment is not just "sent". It moves through states: received, accepted, authorised, validated, held, rejected, routed, sent, settled, booked, returned, recalled, investigated, reported and reconciled.

Each state needs business meaning.

For developers, this means the payment object needs structured lifecycle management, identifiers, timestamps, party data, route data, risk results, posting references and report references.

For testers, it means the happy path is not enough.

For operations, it means queues and statuses must be meaningful, not generic.

13. The lifecycle of a collection

A collection lifecycle begins with a receivable: someone owes money.

The receivable may come from an invoice, bill, subscription, sale, tax, fee, premium or contract.

The collector needs a valid way to request or collect the money. That can be:

• Direct debit mandate.
• Card approval.
• Payment link.
• Open banking approval.
• Request-to-Pay response.
• Local bill-payment method.
• Payer-initiated transfer with reference.

A collection is successful only when authority is valid, the instruction or request is processed, money is received or the result is known, exceptions are handled and the collector can match the outcome to the receivable.

Collections create special events:

• Creditor onboarding.
• Mandate capture.
• Mandate amendment.
• Mandate cancellation.
• Collection file submission.
• Due date processing.
• Debtor-bank reject.
• Post-settlement return.
• Refund request.
• Creditor reversal.
• Card chargeback.
• Dispute.
• Cash application.

The collector cares about debtor-level outcome. A file total is not enough. A merchant settlement total is not enough. A creditor needs to know which customer, invoice, order, mandate or bill was paid.

14. Open banking and request layers

Open banking and request-to-pay are important because they change how customer intent is captured.

A payment initiation service provider can help a customer initiate an account-to-account payment from the customer's account, subject to consent, authentication and applicable regulation. But the PISP is not the settlement rail. The payment still needs the account-servicing PSP and payment infrastructure behind it.

Request-to-Pay is also not the payment itself. It is a structured request that may lead the payer to approve or reject a payment. If accepted, a payment flow may then start through SCT, SCT Inst or another method depending on design.

This separation matters.

If a bank treats request acceptance as completed payment, it may book money too early. If it treats open banking initiation as infrastructure, it may miss the underlying rail, settlement and reporting obligations.

The practical rule is: separate request, consent, initiation, execution, settlement and reporting.

15. Cards and merchant collections

Card payments are part of the European payment landscape, but they are not SEPA credit transfers.

A card transaction can include cardholder, merchant, issuer, acquirer, card scheme, authorisation, clearing, settlement, interchange, merchant service charge, refund and chargeback.

For a customer, a card payment may feel like a payment. For a merchant, it is also a collection and settlement process. The merchant needs to know which sale was authorised, which settlement batch paid, which fee was deducted, which refund was processed and which chargeback was raised.

This is why merchant collections need their own operating lens.

Account-to-account transfers, direct debits and cards all move value, but their authority model, risk model, exception model and reconciliation model differ.

16. Reporting and reconciliation are part of the product

Reporting is how the bank explains the result.

Reconciliation is how the bank and customer prove records match.

A payer needs to know whether money was accepted, executed, rejected, returned or recalled.

A payee needs to know whether money arrived and which reference it carries.

A creditor needs to know which collections succeeded, failed, returned or were refunded.

A merchant needs settlement reports that match sales, refunds, fees and chargebacks.

A corporate treasury team needs account statements, intraday reporting, status reports and cash visibility.

European payments often use ISO 20022 reporting messages such as camt.052, camt.053 and camt.054, but reporting can also be delivered through APIs, dashboards, events or files.

The medium matters less than the quality and traceability of the evidence.

Good reporting preserves identifiers such as EndToEndId, instruction ID, message ID, mandate reference, creditor identifier, remittance information, booking reference, settlement reference, refund reference and account posting details where relevant.

A payment that moved money but cannot be reconciled is not a complete banking service.

17. Risk, fraud and customer protection

Every payment and collection method creates trust questions.

Faster payments improve customer experience but reduce recovery time.

Direct debit improves recurring collections but depends on mandate management and debtor protection.

Card payments support commerce but create authorisation, fraud, refund and chargeback responsibilities.

Open banking improves customer choice but depends on consent, authentication and API reliability.

Request-to-Pay improves transparency but requires clear status and reference linkage.

Risk controls can include:

• Strong customer authentication.
• Entitlement checks.
• Account status checks.
• Fraud monitoring.
• Transaction limits.
• Sanctions screening.
• AML controls.
• Verification of Payee.
• Mandate validation.
• Data privacy controls.
• Operational resilience.
• Incident management.
• Customer communication.

Good product design should make the payment clear, the authority explicit, the beneficiary or collector understandable, the status meaningful and the exception path traceable.

18. Data quality as the hidden foundation

Data quality is one of the most important practical topics in European payments.

Incorrect account data, missing remittance references, stale reachability, wrong mandate references, unclear creditor identifiers, weak customer names, missing status reasons and inconsistent booking references can create failed payments, false positives, customer complaints and reconciliation breaks.

Data should be structured where possible.

Free text remains useful for human explanation, but it should not be the only place where business meaning lives.

The system should clearly store:

• Debtor and creditor.
• Payer and payee.
• Accounts and agents.
• Amount and currency.
• Product and scheme.
• Channel and authority.
• Mandate and remittance.
• Status and reason.
• Route and settlement reference.
• Posting and report reference.

For ISO 20022, pain messages may carry customer initiation, pacs messages may support interbank payment flows and camt messages may support account reporting and notifications. But the message is only useful if the underlying business data is correct.

The September 2026 EPC update deferred the unstructured-address cutoff; it did not remove the need to improve address data. That is not only an XML change. It affects channel capture, APIs, databases, enrichment, screening, mapping and reporting.

19. How to classify any European flow

A practical professional can classify any European flow by asking these questions in order.

This classification turns a vague phrase such as "European payment" into a requirement that can be designed, built, tested and operated.

20. What a BA should take from this overview

A business analyst should not start with acronyms.

Start with the business reason. Then identify direction, parties, authority, boundary, currency, product, scheme, infrastructure, data, status, exception and reporting.

A weak requirement says:

Support SEPA payments.

A stronger requirement says:

Support customer-initiated EUR SEPA Credit Transfers from eligible debtor accounts to reachable creditor PSPs, with validation, fraud controls, status reporting, return handling and customer reconciliation references.

A weak collection requirement says:

Support European collections.

A stronger requirement says:

Support SEPA Direct Debit Core collections for onboarded creditors with mandate references, creditor identifier, debtor PSP reachability, requested collection date, reject, return and refund handling, and creditor receivables reporting.

Precision makes delivery safer because architects, developers, testers and operations teams work from the same business meaning.

21. What a developer should take from this overview

A developer should model payments and collections as structured business objects, not as generic messages.

The object should include parties, accounts, agents, product, scheme, currency, channel, authority, route, state, risk result, posting reference, report reference and reconciliation reference.

Routing should be configuration-driven. Do not hard-code "Europe equals SEPA" or "EUR equals SCT". The system should check country, currency, product, scheme, participant reachability, customer entitlement, channel, limits, calendar and risk outcome.

Events should be traceable. A good system can explain when the instruction was received, validated, held, rejected, sent, settled, booked, reported, returned or reconciled.

That trace is important for operations, customer service, investigations and audit.

22. What a tester should take from this overview

A tester should not test only one happy-path SEPA credit transfer.

Testing should cover:

• Payment and collection direction.
• Euro and non-euro currency.
• Reachable and non-reachable participants.
• Consumer and corporate users.
• SCT and SCT Inst.
• SDD Core and SDD B2B.
• Instant and non-instant timing.
• Card and account-to-account differences.
• Open banking consent failure.
• Request expiry.
• Return, refund, reversal, recall and chargeback.
• Reporting mismatch.
• Reconciliation break.

A strong test case includes expected participant responsibility and expected customer wording.

A beneficiary PSP not reachable for instant payments should not automatically be reported as invalid account. A direct debit refund should not be treated like a credit transfer return. A card chargeback should not be described as an SDD refund.

23. How to study the full Europe module

Start with this overview.

Then study history, because history explains why modern rails coexist.

Then study market structure, because it explains the layers.

Then study boundaries, because Europe, EU, EEA, Eurozone and SEPA are different maps.

Then study participants, because roles define responsibility.

After the first five foundation chapters, move into institutions, infrastructures, regional markets, payment types, collection methods, merchant payments, digital journeys, schemes, rules, risk, operations, reporting and future modernisation.

The right learning order prevents acronym overload. Do not start with one message. Start with the map.

24. Common beginner mistakes

25. Practitioner summary

European payments and collections are a broad, layered ecosystem.

Payments answer the payer-side need to move money. Collections answer the payee-side need to request, receive and match money owed.

SEPA harmonises major euro account-to-account schemes, but it does not replace domestic systems, cards, high-value settlement, open banking, request-to-pay, merchant acquiring, local-currency rails or reconciliation.

A European payment professional normally works through the same set of questions:

• What is the business need?
• Which boundary applies?
• Which currency is used?
• Who participates?
• What authority exists?
• Which product or scheme applies?
• Which infrastructure is used?
• What can fail?
• How will the result be reported and reconciled?

Once that operating model is clear, the later chapters become much easier to understand.

26. Official sources and reference library

This is the common source gateway for the Europe Payments & Collections module. Later chapters can concentrate on teaching and point back here when the learner needs the current rulebook, implementation guide, legal text, participant register or infrastructure specification. Where a source is version-sensitive, use the live landing page and check the effective date shown there before implementation.

European Payments Council: SEPA scope, schemes and participants

• European Payments Council
• SEPA explained and current geographical scope
• EPC List of SEPA Scheme Countries
• SEPA payment schemes
• EPC document library
• EPC scheme participant information
• Overview of EPC scheme participant status
• Criteria for extension of the SEPA geographical scope

Use these pages for current SEPA geography, scheme family, adherence model, participant information and EPC source documents. SEPA geographical scope and actual scheme reachability are not the same thing.

EPC credit-transfer and direct-debit rulebooks and implementation material

• SEPA Credit Transfer rulebook and implementation guidelines
• 2025 SCT rulebook version 1.2
• SEPA Instant Credit Transfer rulebook and implementation guidelines
• 2025 SCT Inst rulebook version 1.2
• SCT Inst Customer-to-PSP Implementation Guidelines
• SEPA Direct Debit Core rulebook and implementation guidelines
• 2025 SDD Core rulebook version 1.2
• SEPA Direct Debit B2B rulebook and implementation guidelines
• 2025 SDD B2B rulebook version 1.2
• Important update about the 2025 EPC payment scheme rulebooks

The live scheme pages are the safest implementation starting points because they expose the rulebook currently in effect together with the relevant implementation guidelines and supporting material.

EPC request, verification and cross-border instant schemes

• SEPA Request-to-Pay
• SEPA Request-to-Pay scheme rulebook v4.0
• Verification of Payee scheme rulebook
• Verification of Payee scheme rulebook now into force
• One-Leg Out Instant Credit Transfer rulebook and implementation guidelines
• 2025 OCT Inst rulebook version 1.2

Request-to-Pay is a request layer rather than settlement. Verification of Payee is a separate verification scheme. OCT Inst covers the euro leg of eligible international instant credit-transfer flows. Keep these concepts separate from SCT, SCT Inst and the clearing or settlement infrastructure used underneath.

European Central Bank and Eurosystem

• ECB payments
• TARGET Services
• T2 professional documentation
• TIPS professional documentation
• TARGET Services Annual Report 2025

Use these sources for TARGET Services, T2, TIPS, T2S, ECMS, central-bank-money settlement, liquidity and professional documentation.

European Commission and EU payment legislation

• European Commission payment services
• SEPA Regulation information
• PSD2 implementing and delegated acts
• Instant Payments Regulation implementation clarifications
• EUR-Lex

Use the Commission and EUR-Lex for the legal and policy layer, including payment-services legislation, the SEPA Regulation, instant-payment obligations and current consolidated legal text.

European Banking Authority

• European Banking Authority
• EBA regulatory and policy activities

Use EBA sources for regulatory technical standards, guidelines, opinions, Q&A and supervisory material relevant to payment services, strong customer authentication, payment institutions and electronic money where applicable.

EBA CLEARING

• EBA CLEARING
• EURO1
• STEP2
• RT1

Use these sources for the current scope, participation model and operational information of EBA CLEARING services. Do not confuse EBA CLEARING, the infrastructure provider, with the European Banking Authority.

ISO 20022 and SWIFT

• ISO 20022
• SWIFT ISO 20022

Use ISO 20022 for the standard, message definitions and repository information. Use SWIFT material when the question is specifically about SWIFT implementation, CBPR+ or SWIFT-network usage. ISO 20022 itself is broader than SWIFT and broader than European payments.

How to use these references in practice

For learning, this chapter gives the operating picture. For implementation, move from the picture to the authority that owns the rule or service.

If the requirement concerns SCT, SCT Inst, SDD Core, SDD B2B, VOP, SRTP or OCT Inst, verify the current EPC rulebook and implementation material.

If it concerns T2 or TIPS, verify the current Eurosystem documentation.

If it concerns a legal obligation, verify the current EU legal text and Commission guidance.

If it concerns STEP2, RT1 or EURO1, verify EBA CLEARING documentation.

If it concerns ISO 20022 structure, verify the ISO repository together with the implementation guide that applies to the actual scheme or network.

A rulebook, a regulation, an infrastructure specification, a message implementation guide and a participant register answer different questions. A bank-grade requirement often needs several of them before the design is complete.

Address-status source checked 4 October 2026: EPC address guidance v2.2.