The ISO 20022 Agent Chain: Who Routes What, and Which Agent Field to Trust

The agent fields split in two. Party agents (DbtrAgt, CdtrAgt) describe the payment and never change. Transport agents (InstgAgt, InstdAgt) describe one hop and are rewritten by every bank that forwards the message. Intermediary agents are forward-looking routing instructions that get consumed as the payment moves. Confuse the two groups and you will build a reconciliation key that breaks at the first correspondent.

Open a pacs.008 and count the places a bank can appear. Debtor agent, creditor agent, instructing agent, instructed agent, intermediary agents one through three, previous instructing agents one through three, plus the account servicer inside the party blocks. Eleven or more slots, several of which will hold the same BIC, and several of which will hold different values in the copy the next bank receives.

This is where new payments analysts lose a week, and where experienced ones lose an afternoon every time they meet a new correspondent. The confusion is not incidental: the fields genuinely do different jobs, and the usage guideline layers that govern them differ per scheme. Here is the mental model that makes them resolve.

What are the two groups of agent fields?

Every agent field answers one of two questions: who is involved in this payment, or who sent this message. Once you sort them into those two buckets, the behavior follows automatically.

Group	Fields	Describes	Changes in transit?
Party agents	DbtrAgt, CdtrAgt	The payment itself	No, constant end to end
Transport agents	InstgAgt, InstdAgt	This one message, this one hop	Yes, rewritten every hop
Routing agents	IntrmyAgt1 to IntrmyAgt3	Where the payment must go next	Consumed as executed
Trail agents	PrvsInstgAgt1 to 3	Where the payment has already been	Accumulated

The party agents are attributes of the payment, like the amount. The transport agents are attributes of the envelope, like a postmark. A bank rewriting the postmark is not changing the letter.

The party agents: constant by design

DbtrAgt is the debtor’s account-servicing institution: the bank of the person or company paying. CdtrAgt is the creditor’s account-servicing institution: the beneficiary’s bank.

These two must survive unchanged from origination to delivery. If the copy the beneficiary bank receives shows a different debtor agent from the one the originating bank sent, something has rewritten the payment’s identity, and that is a defect, not a routing decision.

This is worth stating plainly because it is the most useful invariant in the whole message. When you are investigating a payment across five systems, DbtrAgt and CdtrAgt should read identically in all five. Where they diverge, you have found the hop that broke something. How a technical BA investigates a failed payment uses exactly this technique.

Sitting alongside them are the parties themselves: Dbtr and Cdtr for the actual payer and payee, plus UltmtDbtr and UltmtCdtr when the paying party and the ultimate beneficiary differ, which happens constantly in payment factories and collections. Those are also constant, and they are what sanctions screening actually reads.

The transport agents: rewritten every hop

InstgAgt (Instructing Agent) is the bank that sent this message. InstdAgt (Instructed Agent) is the bank it sent it to.

They live in the group header or the transaction, depending on the message and the guideline, and they are the fields most often misread. They are not the debtor’s bank and the creditor’s bank. They are the two endpoints of this single hop.

Follow a payment from Bank A through correspondent Bank B to beneficiary Bank C:

Hop 1   A -> B
  DbtrAgt  = A          (constant)
  CdtrAgt  = C          (constant)
  InstgAgt = A          (this hop)
  InstdAgt = B          (this hop)

Hop 2   B -> C
  DbtrAgt  = A          (unchanged)
  CdtrAgt  = C          (unchanged)
  InstgAgt = B          (rewritten)
  InstdAgt = C          (rewritten)

The party agents are identical in both messages. The transport agents are completely different. Both messages are correct.

The classic defect: a downstream system reads InstgAgt to answer “which bank sent this payment,” populates a report with it, and the business notices that payments appear to originate from a correspondent rather than from the real originating bank. The system was reading the postmark and calling it the sender. The fix is a one-line mapping change and a hard conversation about how the original data dictionary described the field.

The routing agents: instructions, not history

IntrmyAgt1 is the single most misunderstood field in the chain. It means: route this payment through this agent next, before it reaches the creditor agent. It is an instruction to the receiver about the future, not a record of the past.

That has a consequence people find counterintuitive. When Bank B receives a payment with IntrmyAgt1 = B and forwards it onward, B normally removes IntrmyAgt1 from the message it sends, because the instruction has been carried out. The field is consumed. A payment arriving at the creditor agent with intermediary agents still populated usually means either a longer chain still in progress or a bank that failed to clear the field.

IntrmyAgt2 and IntrmyAgt3 exist for longer chains. In practice most schemes restrict them heavily. CBPR+ constrains intermediary usage, and many domestic schemes forbid intermediaries entirely because the scheme itself does the routing. Before you specify anything that populates these fields, check the net rule across the four guideline layers, exactly as in reading an ISO 20022 usage guideline: a field the base standard allows may be forbidden by your scheme and rejected on arrival.

PrvsInstgAgt1 to 3 are the mirror image: the agents that already handled the payment. They accumulate rather than being consumed, and they exist to give the receiving bank visibility of the path. Support uses them constantly during investigations; almost nothing else reads them.

How is an agent actually identified?

This is the second place integrations break, and it is an entirely separate problem from which field to use.

The FinancialInstitutionIdentification structure offers several ways to name a bank, and schemes differ on which are acceptable:

• BICFI: the BIC. Universal in cross-border, and the one everyone assumes.
• ClrSysMmbId: a clearing system member identifier, for example a US routing number (USABA), a UK sort code (GBDSC), a German Bankleitzahl (DEBLZ), and so on. It pairs a clearing system code with a member identifier.
• LEI: the Legal Entity Identifier, increasingly required by enhanced-data schemes.
• Nm and PstlAdr: name and postal address, allowed in some contexts and heavily restricted in others.
• Othr: a proprietary scheme.

The defect this generates is predictable and expensive. An integration is built against cross-border traffic, maps BICFI only, and works perfectly. Then the same code meets a domestic payment routed on a sort code, BICFI is absent, the mapping produces a null, and the payment either fails validation or routes to a default. The moment your programme touches more than one scheme, the agent mapping needs to handle at least BIC plus clearing system member identifier, and your data dictionary needs to say which identification takes precedence when both are present.

What does a systems analyst need to specify?

Write these six rules down explicitly, because leaving them implicit is what produces the defects above.

1. Which agent fields your system populates, per scheme, and with which identification type in which order of preference.
2. Which fields your system reads for routing, and what happens when the preferred identification is absent.
3. Whether you clear IntrmyAgt1 when you forward a payment you were the intermediary for. This is a real behavior with a real defect if missed.
4. What you do with agents you do not recognise. Reject, route to repair, or route to a default correspondent. Each has a very different operational consequence, and the answer must come from operations rather than from the developer.
5. Which field feeds each downstream consumer. Reporting, screening, and the data warehouse each need a specific agent, and “the bank” is not a specification. This is the downstream impact problem in miniature.
6. That no key is built on an agent field. Reconciliation, deduplication, and tracing use the UETR or the EndToEndId. See which ISO 20022 identifier to trace on for why this matters more than it sounds.

If you are deriving test cases from this, the agent chain deserves its own condition group: one case per identification type, one per missing-identification path, one proving the party agents survive a hop unchanged, and one proving the intermediary is cleared. How to write pacs.008 test cases has the field-by-field method.

The three defects you will actually meet

Reading InstgAgt as the originating bank. Reports, screening records, and customer-facing statements show the correspondent instead of the real sender. Found late, because it looks right on single-hop domestic traffic and only breaks on cross-border.

Populating intermediaries the scheme forbids. The message is schema-valid, passes your internal validation, and is rejected by the scheme. This is the XML traps pattern applied to business rules: valid is not the same as accepted.

Losing the clearing system member identifier. Only BICFI was mapped. Domestic payments arrive with a sort code and no BIC, and the payment cannot be routed. Almost always discovered in production, because test data was built from cross-border examples.

All three are cheap to prevent and expensive to find. All three come from the same root cause: treating “the bank fields” as one concept instead of three.

The takeaway

Sort the agent fields into party, transport, routing, and trail, and their behavior stops being arbitrary. Party agents (DbtrAgt, CdtrAgt) describe the payment and must survive every hop unchanged, which makes them your best divergence check during an investigation. Transport agents (InstgAgt, InstdAgt) describe one message and are rewritten constantly, so nothing durable may be built on them. Intermediary agents are forward-looking instructions that get consumed, not history.

Then handle identification properly: BIC plus clearing system member identifier at minimum, with a stated precedence, or your first domestic payment will not route.

Next in the field-by-field series: amounts and exchange rates, where InstdAmt and IntrBkSttlmAmt are two different numbers that are both correct. The full map is on The ISO 20022 Reference.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: ISO 20022, Payments, Banking, Functional Analysis, Integration