Agent, Intermediary and Correspondent Data

When people first learn cross-border payments, they often focus on the debtor and creditor: who sends the money and who receives it. That is necessary, but it is not enough. A cross-border payment can travel through several financial institutions before it reaches the beneficiary bank. Each institution may play a different role in the payment message, in settlement, in a correspondent-banking relationship and in financial-crime controls. If those roles are represented badly, lost during translation or misunderstood by reviewers, a payment may appear simpler and safer than it really is.

Agent data is therefore the part of the payment story that answers a different question from customer data. Customer data tells us who is economically behind the transfer. Agent data tells us which financial institutions are carrying, routing, settling or receiving that transfer. In ISO 20022, that can include the debtor agent, creditor agent and one or more intermediary agents. In particular message contexts there are also instructing and instructed agents, reimbursement agents, previous instructing agents and other institution roles. Those labels are not decorative XML. They are a structured representation of the banking chain.

The most important mental model is to separate three things that are often mixed together in conversation. The first is the payment role: debtor agent, creditor agent, intermediary agent, instructing agent or instructed agent in a particular message. The second is the commercial or account relationship between institutions, such as a correspondent and respondent relationship supported by nostro or vostro accounts. The third is the actual settlement route, which may use a payment market infrastructure, a correspondent account, a reimbursement institution or a combination of them. A bank can be an intermediary agent in one transaction without being the direct correspondent of every other institution named in the message. Conversely, a bank may have a correspondent relationship with another bank even when it is not an intermediary on a particular payment.

That distinction matters for AML, sanctions, correspondent due diligence, investigations, operations and system design. A sanctions engine needs to know which institution names and identifiers must be screened. A correspondent-banking team needs to know which respondent is using the relationship and whether downstream or nested activity is expected. An investigator needs to reconstruct how a payment moved and which institutions saw which data. A business analyst needs to know whether a field is mandatory, optional or conditional in the relevant usage guideline and what happens when a message is rerouted. A tester needs to prove that a bank does not silently lose an intermediary during transformation.

Start with the roles, not the acronyms

Imagine a corporate customer in India instructs Bank A to pay a supplier whose account is held at Bank D in Canada. Bank A does not have a direct settlement relationship in the relevant currency with Bank D. It may therefore route the payment through Bank B and Bank C. In a serial customer-credit-transfer flow, Bank A is the debtor agent, Bank D is the creditor agent and Banks B and C can appear as intermediary agents as the instruction progresses. The precise representation depends on the message, the market practice and the leg being viewed.

Now imagine the same economic payment is settled using the cover method. The customer payment information can travel directly from Bank A to Bank D in a pacs.008 while the funds are settled separately through correspondents using a pacs.009 COV. The customer-transfer leg and the cover-settlement leg are linked but are not the same message flow. This is exactly why the phrase “the intermediary bank” can be ambiguous. An institution may intermediate the serial customer payment, the cover movement, or both. A good design names the role and the leg explicitly.

ISO 20022 also distinguishes business roles from message-exchange roles. The instructing agent is the financial institution that sends an instruction to the next agent in that message exchange. The instructed agent is the institution receiving that instruction. Those roles can change from hop to hop. The debtor agent and creditor agent are anchored to the underlying customer transfer, while instructing and instructed agent describe the current exchange. This difference becomes important in investigations because a payment can be forwarded, rerouted or repaired after the originating bank created it.

The ISO 20022 standard is intentionally rich enough to describe these relationships. Its message definitions allow structured identification of financial institutions and branches and, depending on message and version, multiple intermediary agents. The exact multiplicities and fields must be taken from the applicable ISO message definition and the relevant market practice, such as CBPR+ or a domestic high-value payment-system guideline. A bank should never assume that because the ISO base message permits a field, a particular scheme permits or requires it in the same way.

Payment agents are not the same as customer parties

A recurring control error is to treat every name in a payment as if it represented the same type of risk. It does not. The debtor and creditor are usually customers or economic parties. The debtor agent and creditor agent are financial institutions serving those parties. An intermediary agent is a financial institution between them in the chain. An ultimate debtor or ultimate creditor may reveal an economic party behind the immediate account holder. These distinctions affect screening logic, name-matching thresholds, investigation expectations and the questions operations should ask.

For example, a payment to a legitimate customer at a non-sanctioned bank can still involve an intermediary institution that creates a sanctions concern. Conversely, a BIC that shares text with a listed entity does not automatically prove that the institution is sanctioned. Screening must resolve the identity, relevant sanctions programme, ownership or control rules, location and legal nexus. The data role tells the control what the field means; it does not decide the legal outcome.

The same principle applies to geographical information. An agent's BIC, LEI, clearing identifier, name, postal address or branch identifier can help determine which institution is involved and where a branch operates. Those values can support risk assessment and screening, but they should not be converted mechanically into a legal conclusion. A bank may have a head office in one country and a branch in another. Sanctions applicability can depend on the legal entity, branch, currency, clearing route and jurisdictional nexus. The control needs enough structure to distinguish those facts.

Why payment transparency depends on the chain

FATF Recommendation 16 is the global standard most closely associated with payment transparency. FATF revised Recommendation 16 in June 2025. As of September 2026, FATF states that countries are expected to be ready to implement the strengthened changes by the end of 2030. That timing matters. The revised standard is globally important, but individual legal obligations depend on national or regional implementation and may not yet be in force everywhere. A bank must therefore map the FATF standard to the laws, regulations and payment-system rules that actually apply to each legal entity and payment route.

The core policy objective is durable: enough originator, beneficiary and payment information should accompany a transfer so that financial institutions and authorities can identify who is involved, apply controls and trace funds. Intermediaries matter because transparency can be weakened if information is stripped, truncated, overwritten, placed in the wrong field or lost when a message crosses systems. The 2023 Wolfsberg Payment Transparency Standards express the same operational concern: payment service providers should accurately reflect participating parties and agents and should not omit, delete or alter debtor or creditor information to avoid detection.

The revised FATF Recommendation 16 also reflects changes in the payments landscape and introduces strengthened transparency and fraud-error protection expectations. FATF published draft implementation guidance for consultation in June 2026. That guidance is not a substitute for local law, and the consultation itself should not be presented as a binding rule. For practitioners, the important point is that payment data architecture being built now must be capable of supporting more structured, reliable and end-to-end information rather than treating transparency as an after-the-fact compliance repair.

FATF Recommendation 13 addresses a related but different problem: correspondent banking. It expects financial institutions entering relevant cross-border correspondent relationships to understand the respondent institution, its business and reputation, the quality of supervision, its AML/CFT controls and the responsibilities of each institution. Depending on the service, the correspondent also needs to understand how the respondent will use the relationship, including downstream or nested arrangements. This is relationship-level due diligence. Recommendation 16 is primarily about payment transparency. They interact, but they are not interchangeable.

Correspondent banking beneath the payment message

A correspondent relationship exists because one institution provides banking or payment services to another institution. A classic example is a bank holding an account for a foreign respondent so that the respondent can make or receive payments in a currency or market where it does not have direct access. In accounting language, one institution may refer to a nostro account and the other to the same balance as a vostro account. The terminology depends on whose books and perspective are being used.

The correspondent bank must understand the respondent's intended use of the service. Is it sending payments only for its own direct customers? Does it provide services to other financial institutions that will indirectly access the correspondent? Are there payable-through-account features that allow underlying customers direct access? Which countries, currencies, products, transaction values and customer types are expected? These questions belong to correspondent due diligence and ongoing relationship monitoring, not to an isolated sanctions-screening event.

Nested correspondent banking is especially important. FATF's correspondent-banking guidance describes nested relationships as downstream banking where other respondent banks gain indirect access through the direct respondent. The existence of nesting is not automatically improper. The concern is opacity. The correspondent should understand that such arrangements exist, where the nested institutions operate and how the respondent formats payment instructions so that involved parties are transparent enough for monitoring and screening.

This creates a direct connection to message data. A relationship team may approve a respondent on the basis that downstream banks are identified transparently. If actual payment messages systematically obscure those institutions, the operational behaviour no longer matches the understood model. Conversely, if an intermediary appears in a payment that was never expected from the relationship profile, that does not automatically prove suspicious activity, but it can create a meaningful question for the relationship owner or financial-crime team.

Serial payments: one instruction moves through the chain

In a serial payment, the customer credit transfer instruction travels through successive institutions. At a simplified level, Bank A sends a pacs.008 to Bank B, Bank B forwards the instruction to Bank C, and Bank C sends it onward to Bank D. Each hop creates an instructing-agent and instructed-agent relationship for that message exchange, while the underlying debtor-agent, creditor-agent and intermediary-agent roles describe the transaction chain.

The operational challenge is to preserve the transaction's meaning while permitting legitimate routing changes. An intermediary may need to select a different downstream correspondent because of currency, cut-off time, market availability or internal routing policy. That can change an intermediary-agent field without changing the economic debtor or creditor. A data model that treats every field as immutable will fail legitimate routing. A data model that allows every field to be overwritten without history will fail traceability.

The right approach is controlled mutability. Certain data should remain linked to the original instruction, while routing data can evolve with a complete audit trail. Systems should know the difference between source data, derived data and amended data. When an intermediary changes the route, the bank should be able to show the previous value, new value, reason, time, system or user responsible and the outbound representation sent to the next institution.

Cover payments: separate customer and settlement legs

Cover payments are frequently misunderstood because the customer-transfer information and the settlement transfer take different routes. In a typical ISO 20022 cover structure, the debtor agent can send a pacs.008 customer credit transfer toward the creditor agent while a pacs.009 COV moves the related cover funds through correspondent institutions. The pacs.009 COV carries underlying customer-credit-transfer information so institutions in the cover chain are not blind to the parties behind the funds movement.

The Payments Market Practice Group's cover-payment guidance emphasises the responsibilities of institutions in this chain. The originating institution must choose the correct message type for a cover payment. Intermediary institutions should pass on the relevant underlying information and meet their own compliance obligations under applicable law. The guidance also recognises that completeness-check obligations can vary by jurisdiction. This is a useful example of why a global course should not turn industry guidance into a universal legal rule.

From a financial-crime perspective, a cover payment creates two evidence trails that must be linked. The investigator may need the pacs.008 customer-transfer leg, the pacs.009 COV settlement leg, the correspondent-account postings, status and notification messages, screening results, RFIs and any routing changes. Looking at only one leg can produce an incomplete story. A screening alert in the cover chain may delay settlement even though the customer instruction reached the creditor agent quickly. Conversely, the creditor agent may be waiting for settlement confirmation before final credit.

For business analysts, the key design question is correlation. What identifiers link the customer leg and cover leg? Which systems hold them? Can operations retrieve both without manually guessing from amount and date? Are references preserved when a message is translated, repaired or returned? This chapter focuses on agent data, while the next chapter goes deeper into UETR, EndToEndId and payment references, but the disciplines are inseparable in a working investigation.

What an agent record should contain

A mature payment platform should not reduce a financial institution to one text field called bankName. The minimum useful model normally includes a role, institution identifier, institution name where supplied, branch information where applicable, address data where supplied or required, clearing-system member identifiers where applicable, and provenance showing where each value came from. Some environments may also use an LEI or proprietary identifier. The exact permissible and required fields depend on message and scheme.

The BIC is especially important in cross-border payments because it can identify a financial institution or business party within Swift-related processes. But a BIC should not be treated as a universal replacement for all other identity data. A BIC can identify an institution or branch in a messaging context; it does not by itself establish beneficial ownership, sanctions status, prudential authorisation or the full legal relationship between institutions. Those questions require other reference data and due-diligence sources.

Branch data deserves specific attention. A sanctions or country-risk concern may relate to a branch location even when the parent institution is elsewhere. If a source message identifies a branch and an internal canonical model drops it because only the institution-level BIC is retained, the bank can lose relevant context. Conversely, systems should not invent branch specificity that the source did not provide. Provenance protects both against data loss and against false precision.

Clearing identifiers can also matter. Domestic legs may use national clearing codes rather than BICs. Cross-border payments can therefore pass through an environment where one system sees a BIC, another sees a clearing-member ID and a third stores a local participant code. Entity resolution should link those identifiers to a controlled financial-institution reference record without destroying the original values. An investigator needs to know both what the original message said and what the bank resolved it to mean.

Structured addresses and the deferred CBPR+ milestone

Agent information is affected by the broader move toward structured ISO 20022 data. Swift originally planned to remove fully unstructured CBPR+ postal addresses on 14 November 2026, but deferred SR2026 payments changes on 27 August 2026. The replacement address-enforcement timetable remains subject to Swift's further announcement. For relevant CBPR+ messages, town name and country must be carried in designated fields at minimum when an address is used; for agents, use of the BIC alone remains a valid option rather than requiring name and address. Readiness remains an implementation concern, while production enforcement must use the confirmed network timetable.

The control implication is not simply “reject unstructured text.” Banks need to know which channels still create unstructured agent or party addresses, which translations could reintroduce them, how vendor applications validate them and how exceptions are reported before the November cut-over. A bank with clean ISO 20022 generation can still fail if an upstream corporate file, legacy payment hub or downstream market-infrastructure adapter converts data incorrectly.

Structured data improves machine processing because country, town, street and other components are distinguishable. That can improve screening precision and reduce ambiguity, but structure does not guarantee truth. A perfectly structured false address is still false. Data-quality controls therefore need both syntactic validation and semantic reasonableness where appropriate.

Data lineage: preserve what was received, what was understood and what was sent

For financial-crime evidence, it is useful to think in three layers. The first is received data: the original message, API payload, file or internal instruction. The second is interpreted data: the canonical party and agent objects, reference-data enrichment and screening representation used by the bank. The third is sent data: the message ultimately transmitted to the next institution or market infrastructure. A defensible system can reconstruct all three.

Suppose a pacs.008 arrives with an intermediary agent identified by BIC. The payment hub resolves the BIC to a legal-entity reference record, adds country information from reference data and presents a normalized name to the sanctions engine. Operations then reroutes the payment and inserts a different downstream intermediary. Months later, an investigation asks what information the bank received and why the original institution was not screened as a party in a specific way. If the platform retained only the final outbound message, the evidence is incomplete. If it retained only normalized names, it cannot prove the source value. If it retained only raw XML, investigators may not know what the screening engine actually saw.

A practical lineage record should therefore capture source message ID, message type and version, role, original field path, original value, normalized value, enrichment source, screening timestamp, screening result, routing decision, change history and outbound field path. Not every bank will implement those as one table, but the information should be reconstructable.

Screening financial institutions in the chain

Payment screening normally includes more than customer names. Depending on legal obligations, policy and system design, financial institutions named in the payment can also be screened against relevant sanctions or internal risk lists. The precise scope should be defined by jurisdiction, product and policy. It is unsafe to teach that every agent always requires the same screening logic in every country.

Agent screening differs from customer screening in useful ways. A bank may have high-quality identifiers such as a BIC or clearing code. That can support stronger identity resolution than a free-text customer name. But sanctions lists do not always provide the same identifiers, and aliases or ownership/control considerations can still matter. Some agent names are abbreviated or appear through branches. The screening engine should preserve role context so an analyst can tell whether a match concerns the debtor agent, an intermediary agent, creditor agent or another institution.

The decision cannot end at “match” or “no match.” A potential sanctions hit can require identity resolution, programme applicability, ownership/control analysis, transaction nexus, licence or exemption review and an operational action such as hold, reject, block, freeze, report or release depending on the applicable regime. Those actions are covered in more depth elsewhere in the course. For this chapter, the important point is that agent data must be complete enough to support the decision and linked to the transaction evidence.

AML monitoring and correspondent activity

Transaction monitoring uses agent data differently. A single payment through a particular intermediary may be perfectly normal. Patterns can become important when compared with the respondent's expected activity, customer profile and corridor history. A correspondent bank may look for unexpected downstream financial institutions, new high-risk corridors, changes in settlement routes, unusual concentration through one intermediary, payment patterns inconsistent with the stated business model, or repeated transparency defects associated with a respondent.

None of those indicators is proof of money laundering. They are contextual signals. An emerging intermediary could reflect a new commercial relationship. A changed route could result from a cut-off-time issue. A spike in one corridor could reflect legitimate seasonality. The investigation should combine message data with respondent due diligence, account activity, customer information, sanctions intelligence and operational evidence.

Nested activity is particularly sensitive because the correspondent may not directly onboard the underlying institution using its respondent's account. The relationship therefore depends on the respondent's controls and transparency. Wolfsberg and FATF guidance both emphasise understanding downstream arrangements. A bank's monitoring architecture should be able to identify and aggregate nested institutions where the data permits, rather than treating every payment as if the direct respondent were the only relevant financial institution.

Missing, inconsistent or improbable agent data

Not every missing intermediary field is a financial-crime event. Some payment routes legitimately have no intermediary. Some schemes derive routing from network or account information rather than populating a particular field. A field may be optional in one usage guideline and required in another. Controls should therefore validate information against the correct message type, version, market practice and processing role.

More meaningful exceptions arise when the message contradicts itself or the operational route. Examples include an agent BIC that does not match the identified branch country, a local clearing code mapped to a different institution, an intermediary expected from the route but absent from the transmitted chain, an unexpected downstream respondent in a correspondent relationship, or a cover payment that uses an inappropriate message type and therefore fails to carry the necessary underlying customer information.

The response should be proportionate. Some defects can be corrected automatically from authoritative internal reference data if policy permits and provenance is retained. Some require operational repair. Some require an RFI to another institution. Some create a compliance hold. Some should be rejected because processing would breach scheme rules or legal obligations. The decision matrix must identify which team can take which action and under what authority.

Do not “repair” away the evidence

Payment repair is a high-risk control point because it allows a human or system to change data after initiation. Repair is necessary in real banking: format errors, invalid identifiers and routing problems happen. The danger is allowing repair to become undocumented rewriting.

A repair user should not be able to remove an intermediary institution simply to make a screening alert disappear. The system should preserve the original message, record the amendment, require a reason, restrict permissions and, for risk-sensitive fields, trigger rescreening. Maker-checker or additional approval can be appropriate for certain changes depending on risk and operational model. The control should be designed around the consequence of the change, not around whether it was made through a manual screen or an API.

If a payment is returned, the return chain may not simply mirror the original chain. Investigation and return messages can carry their own agent data and references. Systems should link them to the original payment without assuming every role reverses mechanically. This is another reason to model roles explicitly instead of keeping a flat list of bank names.

From alert to case to investigation

An agent-related alert should arrive with enough information for an analyst to understand the issue quickly. At minimum, the case view should identify the payment, relevant message and leg, agent role, source value, normalized institution, screening or monitoring reason, route, other involved institutions and related customer parties. If it is a correspondent-monitoring alert, the case should also link to the respondent profile and relationship owner.

The analyst then separates identity from risk. First: is the institution actually the entity of concern? Second: what role did it play? Third: which law, policy or typology is relevant? Fourth: what transaction and relationship context changes the assessment? Fifth: what action is permitted or required? This sequence prevents a common failure where an analyst jumps from a fuzzy name match directly to a payment decision.

An RFI can be appropriate when another institution holds necessary context. The request should be specific: confirm the identity of an intermediary, explain why a particular institution appears in the route, provide underlying institution details in nested activity, or clarify a discrepancy between payment data and the known respondent model. The bank should track the request, response, deadline and final decision as part of the case evidence.

Escalation may go to sanctions specialists, AML investigations, correspondent-banking compliance, legal, operations or the relationship owner depending on the issue. If suspicion is formed under applicable AML law, the bank may need to consider a suspicious transaction/activity report through its jurisdictional process. If sanctions law requires blocking, freezing, rejecting or reporting, that is a separate legal decision. The system should not force all financial-crime outcomes into one generic REJECTED_COMPLIANCE status.

Operational and customer impact

Agent-data controls affect customers even though customers rarely see the fields. A payment can be delayed because an intermediary requires more information, because a cover payment is held for sanctions review, because a BIC is invalid, or because routing must change after a cut-off. The customer may only see “processing” or “pending.” Good operations design translates the internal state into accurate customer communication without exposing sensitive financial-crime reasoning.

False positives create real cost. A payment repeatedly held because an intermediary's name is matched badly can create customer complaints and correspondent friction. The answer is not to suppress the institution from screening. It is to improve identity resolution, reference data, matching configuration and case evidence. Similarly, an institution repeatedly generating incomplete messages may create downstream repair costs that should feed relationship management and service-quality conversations.

Timing also matters. Cross-border payments can involve market cut-offs, FX windows, liquidity positions and downstream service levels. An agent-data exception detected early at initiation is cheaper to fix than the same defect discovered by a downstream correspondent after funds have moved. Preventive validation should therefore happen as close as possible to the source, with later controls still able to detect changes introduced by routing or transformation.

Roles and governance

Ownership should follow the lifecycle. Payment product owners define the service and customer promise. Payments operations own many routing and repair processes. Financial-crime compliance defines policy and escalation standards. Sanctions teams own sanctions interpretation and disposition where applicable. Correspondent-banking teams own respondent due diligence and relationship expectations. Data owners define reference-data quality. Architects and engineers implement role-preserving message models. Test teams prove the controls. Internal audit and second-line assurance independently challenge whether the design and operation are effective.

A useful governance forum does not review only alert volumes. It examines recurring data defects, high-risk route changes, respondent transparency issues, RFI ageing, repair reasons, false-positive drivers, override use, screening coverage, mapping failures and incidents where the received message differed materially from the screened or sent representation. That turns payment transparency from a compliance slogan into an operationally measurable capability.

What business analysts should specify

A BA working on this area should begin with a role-and-source matrix. For each message and payment rail, identify which agent roles can appear, their ISO paths, cardinality, identifiers, branch structures, validation rules, source system and downstream consumers. Then map transformations: which values are copied, normalized, enriched, derived, replaced or removed at each boundary.

Requirements should distinguish syntax from control meaning. “BIC must be 8 or 11 characters” is a format requirement. “The institution resolved from the BIC must be screened when policy requires the relevant agent role to be screened” is a control requirement. “The original BIC, resolved entity and screening result must remain linked in the audit trail” is an evidence requirement. Combining all three into one vague statement such as “validate bank details” is not testable enough.

The BA should also document serial and cover variants, route changes, multiple intermediaries, on-us cases, domestic clearing transitions, rejected messages, returns and investigations. Real defects tend to hide in those variants rather than the happy path.

Architecture considerations

A robust architecture normally has a canonical payment model that preserves role semantics. It should support a debtor agent, creditor agent and the number of intermediary/reimbursement roles needed by the schemes the bank serves. It should not flatten all institutions into an unordered array. Where internal systems use different labels, a controlled mapping should document equivalence and non-equivalence.

Reference-data services can resolve BICs, clearing codes, LEIs and internal institution IDs. Payment screening may consume a normalized representation. Routing engines may choose a downstream correspondent. Case-management systems need the transaction snapshot and later changes. Data platforms may use the same information for monitoring and MI. Every consumer should know whether it is reading original, current or enriched data.

Event-driven architectures introduce another question: ordering. A screening event emitted before reference-data enrichment may carry different institution attributes from a later routing event. If the case system sees only the latest object state, it can misrepresent what the control knew at decision time. Event timestamps, versions and immutable evidence snapshots are therefore important.

Testing: prove that meaning survives the journey

Testing should start with positive structural cases: direct debtor-agent-to-creditor-agent payments; one intermediary; multiple intermediaries where supported; branch identifiers; BIC-only agent identification; name-and-address identification where permitted; and local clearing identifiers. Then test serial routing changes and cover flows.

Negative tests should include invalid BICs, BIC/reference-data mismatch, missing conditional fields, duplicate or contradictory agents, malformed branch data, unsupported identifier schemes, unexpected downstream banks, incorrect cover-message selection and unstructured address formats under both the current CBPR+ profile and the target structured-address profile, with enforcement linked to the confirmed effective date.

Transformation tests are critical. Seed a distinctive agent in the source instruction and prove it appears correctly in the canonical model, screening payload, outbound message, data store and investigation view. Repeat with two or three intermediaries. Then alter the route and verify that the old and new values are both auditable. Test rescreening after repair. Test a return. Test a message translated between legacy and ISO representations where such translation still exists internally.

Non-functional tests should cover screening latency, reference-data outage, duplicate events, message replay, high-volume correspondent flows, case backlogs and degraded routing. A service outage should not silently bypass agent screening unless an explicitly approved fallback policy allows it. The system should record when it operates in degraded mode.

Mini case: the payment that changed route twice

A fictional corporate customer, Northstar Components, instructs Bank A to pay CAD 480,000 to supplier Maple Industrial at Bank D. The customer instruction is legitimate and consistent with Northstar's profile. Bank A creates the customer transfer with Bank A as debtor agent and Bank D as creditor agent. Its routing engine initially selects Bank B as an intermediary because Bank B is the preferred CAD correspondent.

Minutes later, Bank B's route is unavailable for the relevant service window. Bank A reroutes through Bank C. The canonical payment record correctly replaces the current routing agent but retains Bank B in history. Screening runs again on Bank C. Bank C is not listed, and the payment proceeds.

Bank C, however, forwards the payment through Bank E before it reaches Bank D. Bank E is a smaller institution in a jurisdiction that Bank A's correspondent-risk team classifies as elevated. The payment message received downstream identifies Bank E, but Bank A's post-payment monitoring platform originally ingests only the first outbound route and therefore does not capture Bank E.

Two weeks later, an unrelated financial-crime review identifies repeated Bank E activity through Bank C. The investigation asks whether Bank E was expected as a nested or downstream institution and whether the direct respondent relationship with Bank C permits that activity. Operations can retrieve the full message chain, but the monitoring data mart cannot. The issue is not that Bank E is automatically suspicious. The issue is a coverage gap: the bank's relationship and monitoring controls cannot reliably see institutions introduced after the first routing decision.

The remediation has four parts. First, the payment data platform begins ingesting downstream agent updates rather than only the first outbound snapshot. Second, the correspondent-banking team confirms Bank C's downstream model and updates the expected-activity profile. Third, monitoring is tuned to identify previously unseen nested institutions in relevant relationships. Fourth, QA adds a regression test where an intermediary introduces another intermediary after initial screening.

The lesson is not “more intermediaries equal more crime.” The lesson is that financial-crime controls depend on seeing the payment chain as it actually evolved. If the bank stores only the route it planned, it cannot monitor the route that occurred.

Chapter takeaways

Agent data explains the institutional route of a payment. Correspondent data explains relationships that may enable settlement or access. They overlap, but they are not the same thing. ISO 20022 provides richer role-aware structures, but those structures create value only when banks populate, preserve, interpret and transmit them consistently.

For financial-crime purposes, the strongest control model is simple to describe even if it is technically demanding to implement: identify each institution and role accurately; preserve the original and transformed data; screen and monitor according to applicable law and policy; understand respondent and nested relationships; control repairs and route changes; link serial or cover legs; and retain enough evidence to reconstruct what happened.

The final safeguard is humility about jurisdiction. FATF, CPMI, Swift, Wolfsberg and ISO 20022 provide global standards, harmonisation requirements and industry practices, but binding obligations come from the laws, regulations and scheme rules applicable to a particular bank and payment. A good global platform therefore does not hard-code one jurisdiction's interpretation as universal. It provides the data and decision structure needed to apply the right rule in the right place.

Swift timetable source, checked 2 October 2026: Structured-address migration extension and 21 September release update. The deferred release includes exceptions/investigations messages on 12 June 2027; structured-address enforcement timing remains separately governed: https://www.swift.com/news-events/news/swift-accepts-community-request-extend-structured-address-migration-iso-20022-payment-messages

Operational deep dive: reading the institutional payment chain correctly

The base chapter separated payment-message roles, correspondent relationships and settlement routes. This deep dive goes further into the mechanics because most implementation defects happen when those concepts are collapsed into one generic idea of “bank in the chain”. The practical objective is to make a payment reconstructable at three levels: the business transfer between debtor and creditor, the sequence of agents that process it, and the account or market-infrastructure arrangements that move settlement value.

A reviewer who can see only a list of institution names has information but not meaning. A reviewer needs to know which institution was the debtor agent, which was the creditor agent, which was introduced as an intermediary, who instructed whom at each hop, and which correspondent relationship enabled the settlement. The same institution can play different roles in different payments and even different roles on separate legs of the same payment.

The ISO 20022 role model in practical terms

ISO 20022 deliberately distinguishes business roles. In a customer credit transfer, the debtor is the party whose account is debited and the creditor is the party whose account is credited. The debtor agent services the debtor for the transfer and the creditor agent services the creditor. An intermediary agent is an agent between those two. Depending on the message, version and market practice, the model can represent more than one intermediary.

The terms instructing agent and instructed agent answer a different question. They describe the sender and receiver of a particular interbank instruction. If Bank A sends a pacs.008 to Bank B, A is instructing B on that leg. If B then sends the transaction to Bank C, B becomes the instructing agent and C the instructed agent for the next leg. The business identity of the debtor agent does not change simply because the message moved one hop.

This distinction matters in logging. If a transaction table stores only sendingBank and receivingBank, those values can mean the network sender and receiver rather than the underlying debtor and creditor agents. An investigator can then mistakenly conclude that an intermediary was the originating bank. The canonical model should use role-specific attributes and should separately record transport or message-exchange actors.

It also matters in screening. An institution that is the instructed agent on one message may already be represented elsewhere as an intermediary or creditor agent. Screening architecture should avoid both gaps and uncontrolled duplication. The right answer is not necessarily “screen every repeated string every time.” It is to resolve role-aware entities, apply the policy scope and retain enough evidence to show what was screened on which event.

Direct, serial and cover structures

A direct payment is the easiest model. The debtor agent and creditor agent have an arrangement that permits the instruction and settlement to proceed without another payment agent in between. That does not mean no infrastructure is involved; an RTGS or other payment market infrastructure can still settle the payment. “Direct” describes the agent chain, not the absence of systems or settlement mechanisms.

In a serial payment, the customer credit transfer moves through intermediate agents. Each intermediary receives and forwards the instruction. The route can reflect currency access, correspondent relationships, clearing membership, internal routing rules, bilateral agreements, liquidity or cut-off considerations. The financial-crime implication is that every material routing step should remain visible enough for the next institution to perform its applicable controls.

In a cover payment, the customer credit transfer and settlement movement separate. The customer instruction can go from debtor agent toward creditor agent while a financial-institution transfer supplies cover through correspondent banks. Under CBPR+ practice, pacs.009 COV is the dedicated ISO 20022 form for the cover settlement leg because it carries the underlying customer credit-transfer information needed for transparency. PMPG guidance warns against using a plain financial-institution transfer where the cover form is required, because doing so can deprive intermediary institutions of the underlying customer information.

The operational consequence is that a single payment can have two agent chains. A bank must not build one intermediaryBanks[] array and assume it represents both. The customer-transfer route and cover-settlement route need separate but correlated representations. When one leg is held or returned, the platform must identify the effect on the other leg.

Why the cover chain is a financial-crime control problem

Historically, cover payments became an important transparency issue because settlement intermediaries could see only an interbank funds movement without enough information about the underlying customer transfer. The cover-message model addresses that by carrying underlying customer data on the settlement leg. ISO 20022 makes the information richer and more structured than legacy free-text approaches, but the same principle remains: intermediaries cannot apply meaningful controls to information they never receive.

PMPG's February 2024 cover-payment guidance states that intermediary institutions should pass on the underlying information and meet their compliance obligations under the law applicable to them. The guidance is industry practice rather than law. It also recognises that the exact completeness-check obligation can differ by jurisdiction. This distinction should appear in operating procedures. A global operations handbook should not tell every intermediary to follow one country's rule.

A useful system control compares the message type with the payment method. If the route is classified as cover, the payment engine should validate that the correct cover message is used and that the underlying customer-transfer block is present as required by the relevant usage guideline. A mismatch should not be silently repaired by turning a plain interbank transfer into a cover message unless the bank's approved process has sufficient source data and authority to do so.

The investigation view should expose both legs next to each other: customer instruction, cover instruction, their identifiers, parties, agents, screening events, settlement-account entries and status. Without that view, operations can waste time treating a delayed cover as if the creditor bank had never received the customer instruction, or vice versa.

The agent hierarchy and branch problem

Financial institutions are not always represented at one level. A payment may identify a banking group, a legal entity, a branch or an individual payment office. A BIC can be eight or eleven characters in common Swift usage, with branch-level specificity possible. Local clearing identifiers can point to a participant or branch. An LEI identifies a legal entity but not necessarily the operational payment endpoint. Name and postal address may provide still another view.

A control should not force those identifiers into false equivalence. Consider a payment that carries an eleven-character BIC identifying a branch. The reference-data service resolves it to a parent legal entity and also returns the branch country. For sanctions screening, the legal entity may be relevant; for a country restriction, the branch location may also matter; for routing, the exact branch BIC may be essential. Replacing the source BIC with only the parent entity ID loses operational meaning.

The same problem appears with mergers and BIC reassignment. Reference data changes over time. An investigation of a payment from six months ago needs the reference-data interpretation that was valid at transaction time, or at least the ability to reconstruct it. If a current lookup rewrites history, the bank may misstate which institution it believed it was dealing with at the time.

Architecture should therefore treat institution resolution as versioned enrichment. Store the source identifier, resolved entity, resolution method, effective date and confidence or match status. If the resolution later changes, keep the historical interpretation rather than overwriting it silently.

Data completeness is role-specific

A generic “mandatory field” rule is rarely sufficient. The required information depends on the message, payment method, actor role, market practice and applicable regulation. A debtor agent creating a payment has access to different information from an intermediary that receives it. A creditor agent can validate some beneficiary details that an intermediary cannot. An intermediary should generally preserve information received, but it is not automatically responsible for originating every piece of missing customer data.

Wolfsberg's Payment Transparency Standards make this role allocation explicit. They place responsibility on the debtor agent for structuring a new payment appropriately and identifying debtor and creditor. Intermediary agents should pass on complete information received to the fullest extent permitted by the relevant infrastructure and maintain risk-based policies for execution, rejection or suspension. The standards also note the practical limitation that intermediary and creditor agents cannot screen or monitor information that is legally absent from the payment.

For system requirements, completeness rules should therefore carry metadata: ruleSource, jurisdiction, scheme, messageVersion, role, effectiveFrom, effectiveTo and severity. That allows the same payment engine to apply different rules without hard-coding legal assumptions into application logic.

Agent data and structured address migration

The move away from fully unstructured addresses in CBPR+ is a good example of a technical standard becoming a control dependency. The target CBPR+ address model removes fully unstructured postal addresses and uses town and country in designated fields at minimum where required. Swift deferred the earlier 14 November 2026 enforcement plan on 27 August 2026; the current production rule and target readiness rule must remain distinct. Agents may still be represented by BIC alone where permitted.

A bank preparing for that date should test more than message validation. It should examine where an agent address originates, how it is enriched, whether a branch address is being mistaken for head-office address, whether an internal format truncates town names, and whether a translation adapter turns structured data back into free text. It should also distinguish a syntactic CBPR+ rejection from a financial-crime hold so operations do not route all address failures to sanctions analysts.

For a global data programme, the change is useful beyond CBPR+. Structured agent geography can improve corridor analytics and entity resolution. But teams should avoid overclaiming. Structured address data supports better controls; it does not establish that the address is accurate or that the institution is low risk.

Correspondent accounts and payment roles

Correspondent banking often sits beneath the agent chain but should be modelled as its own relationship. If Bank B holds a USD account for Bank A, Bank B is providing a correspondent service to A. Bank A may use that relationship to settle payments in USD. On a particular payment, Bank B could appear as an intermediary agent or as part of a cover route. On another payment, the relationship may not be used at all.

Relationship data should include the respondent, service type, currencies, expected customer types, expected countries, downstream/nested arrangements, products, limits or restrictions, onboarding risk assessment, periodic-review status and any special transparency conditions. Payment monitoring should be able to join transaction agent data to that relationship profile.

This is how a bank can identify a meaningful exception. Suppose a respondent is approved for payments on behalf of its retail and SME customers but not expected to service other financial institutions through the account. If payment messages begin showing recurring underlying banks, the monitoring system should be able to surface that pattern. The issue is not that every underlying bank is suspicious; it is that actual use may differ from the approved relationship model.

Nested relationships: transparent does not mean prohibited

Nested correspondent activity often receives simplified treatment in training. The phrase “nested banking” can sound inherently illicit. That is wrong. FATF guidance recognises nested arrangements and focuses on the need for the correspondent to understand them and the associated risk. The direct respondent should be transparent about how downstream institutions use the relationship, and payment formatting should make relevant parties visible for screening and monitoring.

A bank can therefore have three different concerns. First, known and approved nesting, where downstream institutions are expected and transparent. Second, known but changing nesting, where new downstream institutions or geographies require review. Third, opaque or undisclosed nesting, where transaction data suggests financial institutions are using the account in ways not understood during due diligence.

Monitoring should distinguish those states. A crude rule that alerts every payment containing an additional institution will create noise and discourage useful transparency. A better approach compares observed downstream institutions with the relationship profile and applies higher attention to new, higher-risk or inconsistent patterns.

The relationship owner also needs feedback from transaction monitoring. If monitoring repeatedly sees a downstream institution, the due-diligence profile should not remain frozen until the next periodic review. Event-driven correspondent review can be triggered by material changes in downstream usage, sanctions exposure, regulatory action, country risk or recurring transparency failures.

Mapping from MT-era concepts without carrying old limitations forward

Many bank platforms still contain data models shaped by MT messages: ordering institution, sender's correspondent, receiver's correspondent, intermediary institution and account-with institution. During ISO 20022 migration, teams may map those fields mechanically into debtor agent, intermediary agent and creditor agent structures. That can be necessary for interoperability, but it should not define the target architecture.

ISO 20022 carries richer, more explicitly structured information. If the canonical model has only the old MT-sized fields, the bank can receive rich data and immediately truncate it internally. The migration then changes network format without improving transparency.

The end of the Swift MT/ISO coexistence for cross-border payment instructions in November 2025 reduced one major source of cross-format conversion, but internal legacy systems may still use older representations. An institution can therefore lose data after receiving a valid ISO 20022 message. Internal transformation testing remains essential even when the external network is ISO-native.

PMPG and Swift migration material repeatedly emphasise avoiding data loss and truncation. The control implication is to establish a “no silent loss” principle. If a downstream legacy component cannot carry a data element, the architecture must decide whether to upgrade the component, store the element separately and reattach it, route around the limitation or reject the processing path. Simply dropping the field is not acceptable merely because the legacy system has no column for it.

Sanctions screening: role-aware and evidence-rich

Financial institution screening should preserve the role that caused the name or identifier to be screened. A case saying “ABC BANK hit” is incomplete. The analyst should see “ABC BANK appeared as IntermediaryAgent2 in inbound pacs.008” or “ABC BANK appeared as Cover Creditor Agent on the pacs.009 COV leg”. That context affects both identity resolution and operational disposition.

Identifier-led screening can reduce false positives. If a sanctioned entity record includes a known BIC and the payment carries the same identifier, the match is stronger than a common-name similarity alone. But absence of a BIC match cannot be treated as clearance because sanctions data may contain only names, addresses or other identifiers. Matching logic must combine available attributes under the bank's approved model.

When a branch is involved, the analyst should see the parent relationship without losing the branch. If applicable law treats a branch differently because of geography or legal nexus, legal or sanctions specialists can apply the correct rule. The screening platform should provide facts, not hard-code an unsupported legal conclusion.

Transaction monitoring: route behaviour as a signal

Agent data becomes more powerful when analysed longitudinally. Useful features can include number of unique intermediaries per respondent, frequency of newly seen downstream institutions, corridor changes, proportion of payments requiring agent repair, repeated use of institutions in higher-risk jurisdictions, concentration through a small set of correspondents, or divergence between expected and actual routing.

These features should be interpreted carefully. A new intermediary can be introduced because a bank changes correspondents. A route can shift because of sanctions risk avoidance that is legitimate and policy-driven. A payment market infrastructure may alter participants. Monitoring needs business context and effective dating.

Network analysis can reveal clusters where multiple respondents route through the same downstream institution, or where a supposedly retail-only respondent repeatedly passes transactions involving other banks. Those patterns can generate investigation hypotheses, but the case decision should still use evidence rather than graph appearance alone.

Investigation reconstruction: the “four views” method

A practical investigation can be organised around four views.

View one: message view. What did each relevant message contain? Which agents and parties were present? Which message version and usage guideline applied? Was it serial or cover? Which fields changed between hops?

View two: settlement view. Which accounts or market infrastructures actually moved value? Which correspondent accounts were debited and credited? Were there liquidity or cut-off events that explain routing changes?

View three: relationship view. Which correspondent/respondent relationships existed? Was downstream activity expected? What restrictions or approved business model applied at transaction time?

View four: control view. What did screening and monitoring systems see? Which reference data was used? What alerts, overrides, RFIs or repairs occurred? Who decided and what evidence supported the decision?

These views prevent a case from becoming an XML-reading exercise. Financial crime risk sits in the connection between technical route, economic purpose and relationship context.

Operational exception patterns worth distinguishing

An invalid identifier is primarily a data or routing defect until evidence suggests otherwise. A valid identifier mapped to the wrong institution can be a reference-data issue. A new intermediary can be a legitimate routing change. A removed intermediary after a screening hit is much more concerning because it may indicate an improper repair or attempted avoidance. A respondent repeatedly sending payments with undisclosed downstream banks can indicate a correspondent-risk issue. A cover payment sent as a plain financial-institution transfer can create a transparency failure even if no party is sanctioned.

Those examples should not all generate the same case type. A mature workflow routes technical defects to payment operations, sanctions concerns to sanctions operations, respondent-model concerns to correspondent compliance and suspicious patterns to AML investigations as appropriate. A central case platform can coordinate them, but the decision standards remain distinct.

Evidence retention and reproducibility

A defensible record should allow an independent reviewer to reproduce the decision without relying on current system state. The record therefore needs the original message or immutable representation, reference data used at the time, screening list version or effective date where available, control configuration, analyst decision, approvals, changes and outbound message. If the bank relies on an external screening vendor, it should retain enough evidence of the request and response to show what was evaluated.

For correspondent relationships, the case may also need the due-diligence profile, known nested institutions and restrictions effective on the transaction date. Linking to a live profile without version history is not enough because that profile may later change.

This is where data lineage becomes a compliance capability rather than a data-governance abstraction. Lineage shows not merely that field A mapped to field B, but that the bank preserved the meaning needed to perform and evidence its legal and policy obligations.

Deep-dive conclusion

Agent, intermediary and correspondent data is the connective tissue between payment processing and correspondent risk management. The difficult part is not learning the field names. It is preserving the difference between underlying payment roles, hop-by-hop message roles, settlement arrangements and commercial relationships while allowing legitimate routing to evolve.

A strong bank can answer, for any material payment: who the customer parties were; which financial institutions were involved; what role each played; which institution instructed which; how value settled; which correspondent relationships were used; what changed during processing; what the screening and monitoring controls saw; and why the final decision was reasonable under the applicable rule set. If those questions cannot be answered from retained evidence, the payment chain is not truly transparent even if the XML was syntactically valid.

Swift timetable source, checked 2 October 2026: Structured-address migration extension and 21 September release update. The deferred release includes exceptions/investigations messages on 12 June 2027; structured-address enforcement timing remains separately governed: https://www.swift.com/news-events/news/swift-accepts-community-request-extend-structured-address-migration-iso-20022-payment-messages

Advanced practice: control architecture, BA requirements and testing

A bank can understand the theory of agent data and still implement it badly. The failure usually appears at boundaries: one platform treats an institution as a party, another treats it as a route, a third resolves it to a legal entity, and a fourth sees only the final BIC. This supplement turns the chapter into buildable control architecture and testable requirements.

The governing principle is preserve role, provenance and time. Role tells the bank what the institution meant in the payment. Provenance tells the bank where the information came from. Time tells the bank what the bank knew when it made the decision. Without those three dimensions, an apparently complete payment record can still be unusable for investigation or audit.

Design a canonical agent object before designing screens

A common delivery mistake is to begin with the operations user interface. Teams create fields labelled “Intermediary Bank 1”, “Intermediary Bank 2” and “Beneficiary Bank”, then build the data model behind the screen. That locks the architecture to one product and usually fails when a different message or rail uses different roles.

The better starting point is a canonical financial-institution participant model. The exact implementation varies, but the concept should capture at least:

• transaction identifier and payment leg;
• business role such as debtor agent, creditor agent or intermediary agent;
• message-exchange role where needed, such as instructing or instructed agent;
• sequence or position in the route;
• original institution and branch identifiers;
• original name and address where supplied;
• normalized or resolved institution/legal-entity identifiers;
• identifier scheme, such as BIC, LEI or clearing-system member ID;
• source message, field path, system and timestamp;
• effective status and any subsequent replacement;
• reason for a routing or repair change; and
• links to screening, monitoring and case outcomes.

The object must also allow “unknown” honestly. If the source provides only a BIC and no separate branch address, the system should not manufacture a full legal-entity profile and present it as source data. Reference enrichment is useful, but it must be distinguishable from what the sending institution actually transmitted.

This model allows a bank to answer a subtle but important question: what did the counterparty tell us, and what did our systems infer? Those can lead to different evidential conclusions.

Map each ISO role to each internal system explicitly

A payment hub may use ISO names. A legacy accounting engine may use MT-era names. A sanctions engine may use generic bank_party records. A routing engine may use settlement_agent. A data lake may call everything counterparty_bank. If those names are mapped informally, the risk of semantic loss is high.

The BA should maintain a role-mapping artefact for every boundary. It should state, for example, that DbtrAgt in an inbound pacs.008 maps to debtorAgent in the canonical model, which maps to screening role DEBTOR_AGENT, which is retained as agent_role_code=DA in the analytics layer. If a system cannot distinguish an intermediary from a creditor agent, that limitation should be recorded and remediated rather than hidden behind a generic mapping.

Mappings need conditions. A field that means one thing in pacs.008 may not have the same business meaning in pacs.009 COV or a return message. A previous instructing agent in an investigation or return context is not simply “intermediary agent number four”. The mapping specification should cite the message definition and usage guideline rather than relying on label similarity.

Build a message-and-leg matrix

For this topic, a useful requirements artefact is a matrix with payment method down one axis and message type across the other. Rows might include direct customer transfer, serial customer transfer, cover customer leg, cover settlement leg, return, cancellation/investigation and reporting. Columns identify the messages used by the bank in each market.

For every cell, document which agent roles can occur, which are mandatory or conditional under the relevant usage guideline, how many repetitions are supported, which identifiers are accepted, and which internal systems consume the data. This quickly reveals design gaps. A platform may support three intermediary agents in pacs.008 but only one in its database. A screening engine may accept BIC and name but not branch identifier. A case viewer may display only the first intermediary.

The matrix should be effective-dated because scheme rules change. CBPR+ SR2026 address rules are an example. A format accepted by the current profile may fail the approved target profile. Swift deferred the earlier 14 November 2026 cut-over, so tests must use the subsequently confirmed effective date. Test evidence without the rule version is therefore ambiguous.

Treat reference-data enrichment as a controlled service

Institution reference data often comes from multiple sources: BIC directories, market-infrastructure participant lists, internal correspondent master data, LEI sources, sanctions data, legal-entity masters and local clearing directories. Enrichment is valuable only if the bank knows which source is authoritative for which attribute.

A BIC directory can help identify the BIC holder and branch structure. It should not be used as a substitute for correspondent due diligence. A legal-entity master can connect branches to parents. It should not overwrite a source branch with head-office information. A sanctions vendor can flag ownership links, but the bank still needs a legal interpretation process for applicable ownership/control rules.

The architecture should therefore record enrichment source and date. If two sources conflict, the control needs a precedence or exception rule. Silent “last write wins” behaviour is particularly dangerous for geography because a head-office country can overwrite a branch country that matters to routing or legal analysis.

Reference-data outages also need a defined response. Does the payment stop? Can the platform use a recently cached version? Does it route to manual review? Is screening permitted using source data only? The fallback should be risk-assessed and tested before an outage, not invented during one.

Screening payload design

A screening payload should carry enough context for identity resolution and case display without forcing the screening service to understand the entire payment XML. For each relevant agent, include the role, original identifier, name/address where available, branch information, resolved institution identifier and transaction reference. If the policy requires screening only selected roles, the orchestration layer should make that decision transparently.

Avoid concatenating role and name into one string merely to reuse an old screening interface. INTERMEDIARY2 ABC BANK TORONTO may produce a name match, but it makes audit and tuning harder. Structured screening requests allow the engine and case system to separate matchable content from context.

The response should return a durable screening event ID. That ID should be stored against the exact agent-version screened. If a routing engine later changes IntermediaryAgent2, the new agent requires a new screening decision according to policy. The old screening result should not be inherited simply because the payment ID is the same.

Relationship monitoring joins transaction data to correspondent data

Correspondent monitoring is not complete if it sees only account postings. The monitoring layer should join payment-agent data to the respondent relationship. At minimum, analytics should distinguish the direct respondent from underlying or downstream institutions appearing in transactions.

A practical model can maintain an observed_downstream_institution table keyed by respondent, institution, first-seen date, last-seen date, corridors, volumes and review status. This does not turn every observed institution into a customer. It creates visibility. Relationship owners can then assess whether the observed pattern is consistent with approved nesting and the respondent's stated business.

Monitoring rules can use changes rather than absolute labels: a new nested institution, a new country, a sudden shift in the proportion of financial-institution-originated traffic, or repeated transparency defects. Change-based logic is often more useful than simply alerting on all payments through higher-risk markets.

The model should preserve direction. A downstream bank sending payments through the respondent is different from a bank merely appearing as the beneficiary's creditor agent. Network analytics that ignores role can overstate nested activity.

Control the repair workstation

Payment repair interfaces deserve the same security attention as payment initiation. Users who can edit agent data can change what downstream institutions see and what screening evaluates. The application should therefore implement field-level permissions, reason codes, before-and-after values, timestamps and user identity.

For material agent changes, the workflow should call screening again and reassess routing. If a BIC is changed because the original was invalid, the new BIC should not bypass the same controls that would have applied had it been supplied initially. If a sanctioned intermediary is replaced after an alert, the change should require enhanced approval and documented rationale rather than simply clearing the alert.

A useful anti-evasion control compares repairs with alerts. If the field that caused a screening hit is changed, the case should remain linked to the payment even if the new value no longer matches. Otherwise an operator could unintentionally or deliberately make the evidence disappear by correcting the payment.

Repair metrics are also valuable. High repair rates by a particular channel, respondent or message version can indicate upstream data-quality problems. Repeated agent repairs in one relationship can feed correspondent governance.

Requirement examples that are actually testable

A weak requirement says: “The system shall support intermediary agents.” A stronger requirement states the observable behaviour.

Role preservation: When an inbound pacs.008 contains DebtorAgent, CreditorAgent and supported IntermediaryAgent elements, the payment hub shall preserve each role separately in the canonical payment record and shall retain the original message path and value.

Routing change: When the routing engine replaces or adds an intermediary after initial screening, the platform shall create a new version of the affected agent role, retain the prior value, record the routing reason and trigger the applicable screening policy before outbound release.

Cover correlation: For a cover payment, the platform shall link the customer-transfer leg and cover-settlement leg using approved correlation identifiers and make both legs retrievable from operations and investigation views.

No silent truncation: If a downstream component cannot represent an agent data element required for the outbound scheme or financial-crime control, the transaction shall route to a defined exception path rather than drop the element without evidence.

Evidence: The case-management record shall identify the exact agent role and version screened, source message, normalized identity, screening event ID and disposition.

Correspondent context: Where a payment is processed through a correspondent relationship, monitoring shall be able to associate the direct respondent and any identifiable downstream financial institution with the effective relationship profile.

Those requirements are useful because a tester can prove or disprove them with transaction evidence.

Test design: positive paths first

Positive tests should prove the system can process legitimate complexity. Create direct payments with no intermediary. Create serial payments with one, two and three intermediaries where supported. Use BIC-only identification, branch BICs, clearing member IDs and permitted name/address forms. Use a route change introduced before outbound release. Use a cover payment with correctly correlated pacs.008 and pacs.009 COV legs.

For each test, verify not just the outbound XML. Verify the canonical payment object, screening payload, screening response, routing record, persisted evidence, case view and analytics event. A system can generate perfect XML while its internal monitoring data is wrong.

Use distinctive values so omissions are obvious. For example, make IntermediaryAgent2 a clearly unique test institution and trace that value through every component. If all test banks are named “TEST BANK”, a mapping defect can pass unnoticed.

Negative and boundary testing

Negative tests should cover invalid identifier formats, unknown BICs, branch-parent mismatches, duplicate agent roles, unsupported repetitions, inconsistent country/address data, missing fields required by the applicable usage guideline, wrong message type for cover settlement, and an outbound transformation that drops one intermediary.

Boundary testing should include rule effective dates. Test a fully unstructured address against the current profile and the target structured-address profile separately. Network enforcement must follow the confirmed cut-over; the earlier November 2026 date was deferred. Agents represented only by permitted BIC should continue to work where the usage guideline allows it. This prevents a common mistake: implementing the structured-address change as “all agents must now have postal addresses”.

Test message sizes and long institution names as well. Rich ISO 20022 data can expose hidden length restrictions in internal APIs and database columns. Truncation may not cause schema failure if it occurs before message generation; it can simply produce a different, less transparent institution name.

Evasion and adversarial testing

Financial-crime testing should include deliberate manipulation. Start with a payment that generates an agent screening alert, then attempt to change only the branch, replace the BIC with name/address, remove the intermediary, or reroute through another institution. The expected outcome should reflect policy, but the original alert and modification must remain auditable.

Test a respondent that sends ten payments with a downstream bank clearly identified, followed by a payment where the downstream institution is moved into unstructured remittance text or omitted despite the same operating model. This is not proof of evasion, but the monitoring architecture should make the transparency change visible.

Test serial-to-cover misclassification and cover-to-serial misclassification. The purpose is to prove that the system chooses message structures based on business method, not on whichever template happens to pass validation.

Failure-mode testing

Assume the BIC reference service is unavailable. Assume the sanctions service is slow. Assume the routing engine changes the intermediary after screening. Assume the case-management platform cannot be reached. Assume an event is delivered twice. Assume the same payment is replayed after timeout. For each failure, define whether the payment stops, retries, falls back or routes to manual handling.

A dangerous pattern is “fail open” by accident. For example, the screening orchestrator times out, the payment hub treats no response as no hit, and the payment proceeds. Another dangerous pattern is “fail closed” without operational design, causing a huge queue that operations clear through bulk overrides. Resilience must balance continuity and control through approved, measurable fallback behaviour.

Reconciliation between payment and control populations

A bank should reconcile more than money. It can reconcile the payment population against the screening population: how many payments contained screenable agent roles, how many agent objects were created, how many were sent for screening, how many responses were received and how many were released. Material gaps indicate control coverage issues even when no alert was generated.

The same idea applies to correspondent monitoring. Compare payments processed through respondent accounts with the population available to the monitoring engine. If the ledger shows 1 million postings but monitoring ingested only 970,000 payment records, the issue is not tuning; it is completeness. Population reconciliation is one of the strongest ways to detect silent integration failures.

Management information that leads to action

Useful MI includes agent-data validation failures by source, BIC/reference-resolution failures, route changes after screening, repairs to risk-sensitive agent fields, screening re-runs, RFI volumes, correspondent transparency exceptions, new downstream institutions, aged unresolved cases and payments affected by degraded reference or screening services.

Trend those metrics by channel, respondent, product and message version. A spike immediately after a standards release may point to implementation defects. Persistent defects from one respondent may require relationship engagement. High false-positive rates for one intermediary may justify reference-data or screening tuning.

Avoid using “number of intermediaries” as a stand-alone risk score. Some legitimate cross-border corridors naturally require more intermediation. The risk lies in opacity, unexpected relationships, prohibited exposure, data quality and inconsistent behaviour, not in complexity alone.

Governance and change control

Every scheme or message change that affects agent structures should trigger an impact assessment across payment capture, routing, screening, correspondent monitoring, case management, data stores, reporting and test packs. The 2026 CBPR+ address change is a visible example, but smaller ISO maintenance changes can also affect field rules.

A cross-functional ownership model works best. Payments standards teams interpret usage guidelines. Financial-crime policy teams determine control implications. Data architects update canonical models. Engineers implement mappings and validation. Operations update procedures. Testing teams maintain regression evidence. Correspondent teams assess relationship impact. Legal or regulatory compliance confirms jurisdiction-specific obligations where necessary.

Release evidence should include message examples, mapping changes, data-lineage changes, control coverage tests and rollback/fallback plans. A schema-validation pass is not sufficient proof that financial-crime transparency survived the release.

Advanced-practice conclusion

The technical challenge in agent data is not XML generation. It is ensuring that every system understands the same institution role, preserves the source value, records enrichments separately, responds safely to routing changes and exposes the final evidence to screening, monitoring and investigations.

The strongest acceptance criterion for the whole capability is therefore human-readable: for any selected payment, an independent reviewer can reconstruct every financial institution involved, its role, when it entered or left the route, what the bank knew about it, which controls evaluated it and why the payment was ultimately released, held, returned or escalated. If the architecture cannot support that reconstruction, it is not yet a complete payment-transparency control.

Swift timetable source, checked 2 October 2026: Structured-address migration extension and 21 September release update. The deferred release includes exceptions/investigations messages on 12 June 2027; structured-address enforcement timing remains separately governed: https://www.swift.com/news-events/news/swift-accepts-community-request-extend-structured-address-migration-iso-20022-payment-messages

Practice close: can you reconstruct the bank chain?

The best way to test understanding of this topic is to stop looking at definitions and work through payment evidence. Agent data becomes useful only when a learner can identify what each institution is doing, what the bank can legitimately infer and what still requires investigation.

Scenario 1: direct does not mean infrastructure-free

A customer at Bank A sends a payment to a beneficiary at Bank B. The pacs.008 identifies Bank A as debtor agent and Bank B as creditor agent. No intermediary agent is present. The payment settles through an RTGS system in which both banks participate.

A learner says: “There is no settlement agent because this is a direct payment.” The statement is too broad. The customer-agent chain is direct, but a payment market infrastructure can still provide clearing or settlement. A sound investigation distinguishes the business agent chain from the settlement mechanism rather than assuming they are the same layer.

The control question is whether Bank A and Bank B are represented correctly for the customer transfer and whether the bank can link the message to the settlement evidence. There is no reason to create a fictional intermediary merely because infrastructure exists.

Scenario 2: a BIC mismatch

An inbound payment identifies IntermediaryAgent1 with a BIC that resolves internally to an institution in Country X, but the same agent record contains a postal address in Country Y. The name is common and not enough to resolve the difference.

The wrong response is to automatically label the transaction suspicious. The correct response is to treat the inconsistency as a data-quality and identity-resolution exception. Operations or compliance should establish whether the BIC identifies a branch, whether the address belongs to the same institution, whether the sender used stale information or whether a mapping error occurred.

If applicable sanctions or country controls depend on branch geography, the payment may need to remain on hold until the identity is clear. The case evidence should retain both original values. “Correcting” the address to match reference data without preserving the source would destroy useful evidence.

Scenario 3: a new downstream bank

A direct respondent normally sends corporate customer payments. Over two weeks, messages begin identifying another financial institution behind the respondent. The underlying bank is not sanctioned.

The first question is not “should we block it?” It is “what role is that bank playing, and is that role consistent with the correspondent relationship we approved?” If it represents nested access, the relationship team may need to understand the arrangement. If it is merely a common routing intermediary, the conclusion can be different.

The analyst should therefore combine transaction role data with the respondent's due-diligence profile. Role-blind monitoring cannot make that distinction reliably.

Scenario 4: cover payment with the wrong message type

A bank chooses the cover method for a customer payment but sends the settlement as a plain financial-institution transfer that does not carry the expected underlying customer-transfer information.

Even if every institution name is legitimate, the transparency control can still fail. Cover practice exists specifically so settlement intermediaries can receive the underlying information needed for controls. The bank should investigate why the wrong message type was selected, whether downstream institutions received sufficient information, whether the payment should be rejected or repaired under the applicable rules, and whether similar transactions exist.

Do not turn PMPG guidance into a universal legal statement. The bank must map the industry practice to the law, scheme rules and policy that apply to its legal entity and route.

Scenario 5: routing after screening

A payment is screened with Bank C as its intermediary. The routing engine then replaces Bank C with Bank D because Bank C is unavailable. The payment is released without screening Bank D.

This is a classic sequencing defect. Screening was performed, but not on the institution that ultimately carried the payment. The remediation is not only to screen Bank D manually. The orchestration must bind screening to the current agent version and force re-evaluation when a risk-relevant route changes.

Testing should recreate the exact sequence: initial route, successful screening, route replacement, outbound release. The expected result is that the release gate recognises the changed agent and requires the applicable control outcome.

Scenario 6: rich inbound ISO, thin internal database

A valid ISO 20022 payment arrives with two intermediary agents and structured branch information. The legacy payment database stores only one intermediary and a 35-character institution name. The outbound message is reconstructed later from that database.

This is not merely a technical limitation. The architecture creates predictable data loss that can weaken screening, transparency and investigations. A “no silent loss” control should identify the incompatibility. The bank may need to modernise the database, preserve rich data in a side store that is reliably reattached, or route the payment through a system capable of retaining the required information.

A migration that accepts ISO 20022 on the network while internally reducing it to legacy semantics has not achieved end-to-end transparency.

A review checklist for practitioners

When analysing any payment with multiple institutions, start by asking what role each institution plays. Then ask how it was identified, which message carried it, who supplied it, whether the bank enriched it, whether the route later changed and whether the control systems saw the same version that was ultimately sent.

For correspondent activity, add relationship questions: which institution is the direct respondent, whether other banks gain indirect access, whether such activity was disclosed and approved, and whether transaction behaviour still matches the relationship profile.

For screening, ask which agents are in scope under applicable policy, what identifiers and names were evaluated, which sanctions data and rules applied, whether a potential match was resolved correctly and whether a later repair or route change invalidated the original screening decision.

For evidence, ask whether an independent reviewer can retrieve the original message, canonical interpretation, reference-data enrichment, route history, screening event, repair history, outbound message and final payment or case outcome.

BA acceptance-criteria exercise

Take the vague statement “Intermediary bank details must be available for compliance” and turn it into testable criteria.

A good answer should specify the supported agent roles, relevant message types, source field paths, identifier types, persistence rules, screening hand-off, route-change behaviour, repair audit, case display and outbound preservation. It should state which rule source determines mandatory or optional fields and should be effective-dated where standards change.

It should also define the failure path. If an intermediary cannot be resolved, does the payment stop, route to manual repair or continue with source data? If the screening service is unavailable, what fallback is approved? If the outbound scheme cannot carry the received structure, what happens rather than silently dropping it?

The requirement is complete only when normal processing, exception processing and evidence are all described.

Tester challenge: prove role preservation

Create a test payment where the debtor agent, three intermediaries and creditor agent all have deliberately distinctive identifiers. Send it through every normal transformation. For each stage, compare the role and value against the source. Then make the routing engine replace the second intermediary and prove the original value remains historically visible while the new value is screened and sent.

Repeat the exercise for a cover payment and verify that the customer and cover legs remain separately visible and correlated. Then create a return and confirm that the system links the return chain without pretending the original roles simply reverse.

This test is stronger than checking one final XML file. It proves that meaning survives the system journey.

Analyst challenge: separate facts, inferences and conclusions

Suppose a case contains this evidence:

• a new intermediary appears in a higher-risk jurisdiction;
• the institution is not on the bank's sanctions lists;
• the payment purpose is consistent with the customer profile;
• the respondent did not list that institution as a known downstream bank; and
• the institution appears in 40 similar payments over a month.

The facts are the observations above. An inference might be that the institution could be a new nested respondent or a recurring routing bank. The investigation should determine which. The conclusion should come only after relationship and route evidence is reviewed.

Calling the institution “an undisclosed nested bank” before proving its role converts an inference into a fact. Calling the activity “safe” merely because sanctions screening cleared it makes the opposite error. Good investigations preserve the distinction.

Knowledge check

Why is a correspondent relationship not the same as an intermediary-agent role? A correspondent relationship is an ongoing service/account relationship between financial institutions. Intermediary agent is a role in a particular payment chain. A correspondent may act as an intermediary on some transactions but the concepts are not equivalent.

Why should instructing and instructed agent be stored separately from debtor and creditor agent? Because instructing/instructed roles describe a specific message exchange and can change hop by hop, while debtor and creditor agents describe roles in the underlying customer transfer.

Why is BIC-only data sometimes sufficient for an agent under CBPR+ even as structured-address requirements tighten? Swift's SR2026 guidance allows agents to be identified by BIC alone in relevant circumstances. The deferred address change should not be misimplemented as a universal requirement for every agent to carry a postal address.

Does a new intermediary prove sanctions evasion or money laundering? No. It is context. It can reflect legitimate routing. Concern increases when the institution is prohibited, inconsistently represented, deliberately hidden, or inconsistent with a known correspondent relationship or customer profile.

What should happen when an agent changes after screening? The platform should treat the changed agent as a new control-relevant version and apply the required screening or other checks before release, while retaining the prior value and decision history.

Why are serial and cover payments modelled separately? Serial payments move the customer instruction through intermediaries. Cover payments separate customer-transfer information from settlement funding. Their agent chains and evidence are related but different.

Final practice standard

A learner has mastered this chapter when they can take an unfamiliar payment, draw the institutional chain accurately, distinguish payment roles from correspondent relationships, identify where controls should operate, recognise when data has been lost or rewritten, and explain what evidence is still needed before making a financial-crime conclusion.

That is the professional standard. The objective is not memorising XML tags. It is being able to follow the money and the institutions carrying it without losing the legal, operational and data meaning of each step.

Swift timetable source, checked 2 October 2026: Structured-address migration extension and 21 September release update. The deferred release includes exceptions/investigations messages on 12 June 2027; structured-address enforcement timing remains separately governed: https://www.swift.com/news-events/news/swift-accepts-community-request-extend-structured-address-migration-iso-20022-payment-messages

Masterclass: the transparent message and the opaque relationship

This masterclass uses a fictional case to connect payment-agent data with correspondent due diligence. The facts are invented for learning, but the control questions are realistic. The purpose is not to teach that a complicated route is suspicious. It is to show how a bank distinguishes legitimate payment complexity from a transparency problem by combining message data, respondent expectations and investigation evidence.

The starting relationship

Northbridge Bank, a large international bank, provides USD correspondent services to Meridian Bank, a mid-sized bank in Country M. Meridian was onboarded three years earlier. Its correspondent due-diligence file states that the USD account will mainly support commercial payments for Meridian's corporate and retail customers. Meridian disclosed that it may process some payments for two smaller domestic financial institutions, both named and assessed during onboarding. Northbridge's risk appetite permits that limited nested activity subject to payment transparency and ongoing monitoring.

The relationship profile records expected monthly volumes, main corridors, customer segments and the two known downstream banks. It also states that any material expansion of downstream financial-institution activity should be notified to Northbridge. The arrangement is not a legal guarantee that every future payment will contain the same institutions, but it gives monitoring teams a baseline.

For two years, transaction behaviour broadly matches the profile. Payments involving the two disclosed downstream banks appear transparently in the data. Northbridge's monitoring engine can associate those institutions with Meridian. Periodic review finds no material issue.

A new institution appears

In May, Northbridge's analytics identify a third downstream institution, Horizon Savings Bank, appearing in the agent chain of several payments through Meridian's USD account. The messages are syntactically valid. Horizon is not on a sanctions list and is not inherently prohibited. The first payments are therefore not stopped merely because Horizon is new.

What creates the control question is the relationship mismatch. Horizon was not listed among Meridian's expected downstream institutions, and its business location is in a region Northbridge treats as elevated for corruption and sanctions-evasion exposure. The monitoring alert is correctly phrased as “new downstream financial institution inconsistent with current correspondent profile”, not “suspicious bank”.

An analyst reviews the payment messages. In a set of pacs.008 transactions, Meridian is the instructing institution to Northbridge for the relevant leg. Horizon appears in the underlying chain associated with customers whose payments are being sent through Meridian. The analyst verifies that Horizon's identifiers resolve consistently to the same institution and that there is no obvious sanctions match.

The first wrong conclusion to avoid

A less experienced reviewer might close the alert because all payments are below an internal amount threshold and Horizon is not sanctioned. That would miss the purpose of the alert. Correspondent risk is not limited to listed entities or large-value transfers. The question is whether Meridian is allowing a new financial institution to access Northbridge's correspondent service indirectly and, if so, whether that arrangement is understood and within risk appetite.

The opposite error would be to block every payment immediately because an undisclosed nested bank appeared. That may also be unjustified. The payment data establishes a relationship question, not automatically a legal prohibition.

Northbridge therefore opens a correspondent-risk case and asks Meridian for clarification. The RFI is specific. It asks whether Meridian has established a relationship with Horizon, what services Horizon accesses through Meridian, when the arrangement began, the expected payment activity, customer types and geographies, and how Meridian applies AML/CFT and sanctions controls to that activity. It also asks Meridian to confirm how Horizon is represented in payment messages.

The response changes the picture

Meridian replies that it began providing USD clearing access to Horizon six weeks earlier after a domestic acquisition changed its business. The relationship was approved internally at Meridian, but the correspondent-relationship team failed to notify Northbridge. Meridian supplies due-diligence information, expected volumes and a description of controls. It also confirms that Horizon should be identified transparently where it is the underlying financial institution.

At this point, Northbridge has a governance breach against the agreed relationship expectations, but still not proof of money laundering. The case is escalated to the correspondent relationship owner and financial-crime compliance. They assess Horizon's business, supervision, customer base, country exposure and Meridian's control framework under the bank's correspondent due-diligence policy.

During that review, the data team discovers a second issue. Horizon appears transparently in roughly two-thirds of the sampled payments, but in the remaining third the payment warehouse shows only Meridian and the creditor agent. Raw message retrieval demonstrates that some of those payments did contain Horizon in an intermediary or underlying financial-institution field. An internal transformation dropped the additional institution before the record reached correspondent monitoring.

This changes the case again. There are now two separate problems: a relationship-governance failure at Meridian and a monitoring-data coverage failure at Northbridge. Treating them as one “respondent issue” would allow Northbridge to miss its own control defect.

Reconstructing the evidence chain

The investigation creates a transaction sample across three periods: before Horizon's relationship began, the six weeks after it began, and the period after Northbridge opened the case. For each sampled payment, the team retrieves the inbound message, canonical payment object, agent list, screening request, route history, outbound message, settlement posting and monitoring record.

The comparison shows that screening itself was not bypassed. Where Horizon appeared in the inbound message, the screening orchestration did evaluate it. The defect occurred later: the analytics transformation retained only the first intermediary when creating the correspondent-monitoring fact table. Payments with Horizon as a second or later institution therefore disappeared from the downstream-institution view.

This distinction matters. A bank that says “Horizon was screened” can still have an AML monitoring gap. Screening asks whether the institution matches a sanctions or risk list under the relevant policy. Correspondent monitoring asks whether the activity is consistent with the approved relationship and whether patterns require further investigation. Passing one control does not prove the other is effective.

Legal and policy scoping

Northbridge's compliance team also checks which obligations are legal and which are contractual or policy-based. FATF Recommendation 13 is an international standard for correspondent relationships and is implemented through local legal and supervisory frameworks. Northbridge's specific notification expectation for new nested relationships comes from its contract and policy. The payment-data requirements arise from applicable transfer-of-funds regulation, scheme rules and the bank's own transparency standards.

Keeping those sources separate improves decision quality. The case report does not claim that “FATF law requires Meridian to notify Northbridge within X days” because FATF does not create that direct contractual deadline. Instead, it states the actual basis for each expectation.

Outcome

Northbridge does not automatically terminate the relationship. After enhanced review, Horizon falls within risk appetite subject to conditions. Meridian must provide updated downstream-institution information, strengthen its change-notification governance and demonstrate that payment formatting consistently identifies underlying institutions as required. Northbridge updates the correspondent profile and increases monitoring for a defined period.

Internally, Northbridge fixes the data transformation so all supported intermediary and underlying financial-institution roles reach the monitoring layer. It backfills the affected period and performs a lookback to determine whether other respondent relationships suffered the same coverage issue. The change is regression-tested with payments containing multiple intermediaries and nested institutions.

The relationship team also adds an event-driven review trigger: when transaction data shows a newly observed downstream institution above a risk-based persistence threshold, the system creates a review task even if no sanctions hit exists. The threshold is designed to prevent one-off routing banks from being mistaken for nested respondents; role semantics and relationship context are part of the logic.

What the masterclass teaches

This case demonstrates why payment-agent data cannot be owned by one control function. The payment was syntactically valid. Screening worked. Settlement worked. Yet the bank still had a meaningful correspondent-risk gap because its monitoring view was incomplete and the respondent's business model had changed.

It also shows why “nested banking” is not an automatic adverse conclusion. Horizon's indirect access required understanding, due diligence and transparent message handling. Once Northbridge obtained the missing context and fixed its own data, it could make a risk-based relationship decision rather than reacting to the word “nested”.

Finally, the case shows the value of role-aware evidence. Had Northbridge stored only institution names without message roles, it might have counted ordinary creditor agents as downstream respondent banks and flooded the team with false alerts. The quality of the control depends on knowing why each institution is in the payment, not merely that its name appears somewhere in the record.

Questions a senior reviewer should be able to answer

At closure, a senior reviewer should be able to explain whether Horizon truly used Meridian's correspondent access, which payment roles demonstrated that use, when the activity started, whether it was within the original relationship understanding, whether sanctions screening covered Horizon, whether transaction monitoring saw the full population, what Meridian explained, what Northbridge independently verified, which obligations came from law versus policy or contract, and why continuation of the relationship was within approved risk appetite.

If any of those answers depends on guesswork, the case is not ready to close. The standard is not a long narrative for its own sake. It is a reproducible connection between payment data, relationship evidence, control operation and accountable decision.

References and further reading

These are the public sources used to shape this chapter. FATF standards require implementation through national or regional frameworks; CPMI harmonisation requirements and industry guidance from Wolfsberg, Swift/PMPG and ISO 20022 should not be presented as universally binding law. Banks should always map them to the laws, regulations, payment-system rules and internal policies applicable to the relevant legal entity and payment route.

Global AML/CFT and payment-transparency standards

• Financial Action Task Force, The FATF Recommendations, as amended June 2026. Recommendation 13 addresses correspondent banking and Recommendation 16 addresses payment transparency: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html
• Financial Action Task Force, Guidance on Correspondent Banking Services. Practical guidance on respondent due diligence, nested relationships and transparency of downstream activity: https://www.fatf-gafi.org/content/dam/fatf/documents/reports/Guidance-Correspondent-Banking-Services.pdf
• Financial Action Task Force, Public consultation on guidance to increase payment transparency, 24 June 2026. This explains the June 2025 revision of Recommendation 16 and FATF's expectation that countries be ready to implement the strengthened changes by the end of 2030: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/R16-Public-Consultation-June-2026.html

ISO 20022 and cross-border harmonisation

• Bank for International Settlements, Committee on Payments and Market Infrastructures, Harmonised ISO 20022 data requirements for enhancing cross-border payments – updated report, 26 February 2026. The report clarifies that the harmonisation requirements are guidance rather than regulation and supports alignment through the end of 2027: https://www.bis.org/publications/harmonised-iso-20022-data-requirements-enhancing-cross-border-payments-updated-report
• ISO 20022, Message Definitions Catalogue. Official source for current message definitions, including the pacs payment messages and their data structures: https://www.iso20022.org/iso-20022-message-definitions
• ISO 20022, Repository / e-Repository. Official source for the ISO 20022 Data Dictionary and Business Process Catalogue: https://www.iso20022.org/iso20022-repository/e-repository

Payment transparency and correspondent banking practice

• The Wolfsberg Group, Payment Transparency Standards, 2023. Sets out payment-transparency expectations across debtor, intermediary and creditor agent PSPs: https://wolfsberg-group.org/resources/legacy/136
• The Wolfsberg Group, Guidance on Payment Transparency – Roles and Responsibilities, 2024. Supplements the Payment Transparency Standards with payment-chain role guidance: https://wolfsberg-group.org/resources/203/200
• The Wolfsberg Group, Correspondent Banking and Payments resources. Includes the CBDDQ, Financial Crime Principles for Correspondent Banking and current supporting material: https://wolfsberg-group.org/resources/correspondent-banking
• The Wolfsberg Group, Financial Crime Principles for Correspondent Banking, 2022 publication page. Covers risk-based assessment of respondent relationships and correspondent-banking activity: https://wolfsberg-group.org/news/42
• Basel Committee on Banking Supervision, Sound management of risks related to money laundering and financing of terrorism, current 2020 version. Includes supervisory and bank risk-management guidance relevant to correspondent banking: https://www.bis.org/publications/202007-guidelines-sound-management-risks-related-money-laundering-and-financing-terrorism-revisions-supervisory-cooperation

Swift and Payments Market Practice Group guidance

• Payments Market Practice Group / Swift, Cover Payments – Market Practice Guideline, February 2024. Covers pacs.009 COV, underlying customer-credit-transfer information, BIC use and intermediary responsibilities: https://www.swift.com/sites/default/files/files/pmpg-cover-payments-market-practice-guidance-v4-february-2024.pdf
• Swift, CBPR+ payment instructions – pacs.009 COV. Introductory material on the ISO 20022 cover-payment message and migration from MT 202 COV: https://www.swift.com/pt/node/309854
• Swift, Unstructured address data is being removed. Are you ready?. Earlier migration background; the November 2026 timetable is superseded by the later release announcement: https://www.swift.com/standards/iso-20022/removal-unstructured-address
• Swift, ISO 20022 in bytes for payments: Call-to-action for November 2026. Earlier migration background; the November 2026 timetable is superseded by the later release announcement: https://www.swift.com/ru/node/310589
• Swift, ISO 20022 for Financial Institutions. Cross-border migration context, interoperability and the importance of avoiding data loss or truncation across payment chains: https://www.swift.com/es/node/310120

Swift timetable source, checked 2 October 2026: Structured-address migration extension and 21 September release update. The deferred release includes exceptions/investigations messages on 12 June 2027; structured-address enforcement timing remains separately governed: https://www.swift.com/news-events/news/swift-accepts-community-request-extend-structured-address-migration-iso-20022-payment-messages