ISO 20022 Amounts and FX: Why InstdAmt and IntrBkSttlmAmt Differ

IntrBkSttlmAmt is what moves between banks and is mandatory. InstdAmt is what the debtor asked for, is optional, and may be in another currency. When they differ, exactly one of three things happened: a conversion, a charge deduction, or a defect. The exchange rate fields document what was done; they are not inputs for recomputing anything.

An operations analyst asks why the beneficiary received 9,987.40 when the customer instructed 10,000.00. The developer says the message is correct. Both are right, and the answer is in three fields that most people read as one.

This is part of the field-by-field track of The ISO 20022 Reference, following the agent chain. Amounts are where an apparently simple concept turns out to carry four different numbers, and where a mapping defect costs real money rather than a rejection.

What are the amount fields in a pacs.008?

Four matter. Two are amounts, two describe how they relate.

Field	Meaning	Status in pacs.008
IntrBkSttlmAmt	The amount settled between the two agents, in settlement currency	Mandatory
InstdAmt	The amount the debtor instructed, in the instructed currency	Optional
XchgRate	The rate applied when a conversion occurred	Conditional
ChrgBr	Who bears the charges: DEBT, CRED, SHAR, SLEV	Mandatory

Plus ChrgsInf, a repeating block recording charges actually taken, covered in full in ISO 20022 charges.

The one to internalise: IntrBkSttlmAmt is the real movement of money between the banks. It is what settles, what the RTGS debits, and what reconciliation matches on. InstdAmt is the customer’s intent, carried along for transparency.

When are the two amounts equal, and when not?

On a straightforward domestic payment in a single currency with SLEV or SHAR charges, they are equal, which is why so many systems are built assuming they always are.

They diverge in exactly three situations:

1. A currency conversion happened. The debtor instructed 10,000.00 EUR, the settlement currency is USD, and IntrBkSttlmAmt holds the converted USD figure with XchgRate recording the rate used. Both numbers are correct and in different currencies.

2. Charges were deducted from the principal. With ChrgBr of DEBT or SHAR, an agent in the chain may take its fee out of the amount passing through. The settlement amount to the next agent is then lower than what arrived, and ChrgsInf should record who took what.

3. A defect. A mapping overwrote one field with the other, a conversion was applied twice, or the instructed amount was populated from the settlement amount on a hop that did no conversion.

Your specification must state, per flow, which of the first two are permitted. “Amounts may differ” is not a specification. “On EUR-to-EUR domestic flows the two amounts must be equal; any inequality is an exception routed to repair” is.

How does the exchange rate actually work?

This is the part that generates the most confident wrong assumptions, so be precise.

XchgRate records the rate that the converting agent applied. It exists for transparency, audit, and regulatory reporting. It is documentation of a completed action.

What it is not: an instruction, a quote, or an input for recomputation. If a downstream system takes InstdAmt, multiplies by XchgRate, and compares the result to IntrBkSttlmAmt, it will find mismatches constantly, and they will not be defects. Rounding happens at a currency-specific precision. Spread may be embedded in the rate or taken separately. The rate may be quoted against a unit currency rather than the pair you assumed. Building a reconciliation break rule on that arithmetic produces a queue of false positives that operations will learn to ignore, which is worse than having no check.

Alongside it you will meet CtrctId, a reference to a pre-agreed FX contract, used when the customer negotiated a rate in advance, and in some messages UnitCcy, which removes ambiguity about the direction of the rate. Where the guideline permits UnitCcy, insist on populating it. A rate of 1.0847 between EUR and USD is unambiguous to a human and genuinely ambiguous to a mapper.

The analyst question worth asking early: who converts, and at which hop? The debtor agent, an intermediary, or the creditor agent. That single decision determines which agent’s rate applies, which agent’s spread the customer pays, and which system must hold the FX capability at all. It is a business decision that arrives disguised as a technical one.

The two traps that are not about business rules

Currency is an attribute. In ISO 20022 XML, the amount element carries the value as its text and the ISO 4217 currency as a Ccy attribute:

<IntrBkSttlmAmt Ccy="EUR">9987.40</IntrBkSttlmAmt>

A mapper that reads element text and ignores attributes returns 9987.40 with no currency. This works flawlessly in a single-currency test environment and fails silently the first time a foreign currency arrives, because the amount is still populated and the currency defaults to whatever the system assumed. It is among the most common ISO 20022 mapping defects and it belongs on the same checklist as the other XML traps.

Precision is per currency. The schema allows up to five fractional digits so it can carry every currency, which means schema validation will never catch a wrong-precision amount. The business rule is external:

Currency	Minor units	Valid	Invalid
JPY	0	10000	10000.00 in some guidelines
EUR, USD, GBP	2	9987.40	9987.401
BHD, KWD, TND	3	9987.401	9987.4012

A validator hardcoded to two decimals rejects valid yen and accepts invalid dinar. Your test set needs one currency from each of the three groups, which is exactly the “boundary” category from building a test plan.

What to specify, and what to test

Six statements that need to exist in writing:

1. Which amount drives each downstream consumer. Accounting, limits, screening thresholds, and customer statements each need a specific one, and the answer differs between them. Screening thresholds usually apply to the settlement amount; the customer statement usually shows the instructed amount.
2. Whether the two amounts may differ on each flow, and the exception path when they do unexpectedly.
3. Which agent performs conversion, and therefore whose rate and spread apply.
4. The rounding rule, stated to the currency’s minor units, including the direction.
5. Whether XchgRate is mandatory when the currencies differ. Most guidelines say yes; your validation should enforce it rather than trusting the sender.
6. That no reconciliation rule recomputes an amount from a rate. Match on the settlement amount, which is the number that actually settled.

For test conditions, the high-value cases are: same-currency with equal amounts, cross-currency with both amounts and a rate present, cross-currency with the rate missing (must reject), each of the three precision groups, an amount at the scheme maximum and one above it, and a zero or negative amount which must be refused outright. Derive them the way pacs.008 test cases does, one rule violated per case so the failure is diagnosable.

Back to the opening question

The customer instructed 10,000.00 and the beneficiary received 9,987.40. Read four fields in order and you have the answer in under a minute:

• InstdAmt is 10000.00 EUR, IntrBkSttlmAmt is 10000.00 EUR. Same currency, no conversion, so FX is not the cause.
• ChrgBr is SHAR.
• ChrgsInf shows an intermediary took 12.60 EUR.

Not a defect. A charge, correctly recorded, taken by a correspondent, and entirely invisible to anyone reading only the settlement amount. Which is exactly why the charges block is the next article in this track.

The takeaway

IntrBkSttlmAmt is the money that moved and is mandatory. InstdAmt is what the customer asked for and is optional. When they differ, it is a conversion, a charge, or a defect, and your specification must say which are permitted per flow. XchgRate documents a completed conversion and must never be used to recompute an amount.

Then handle the two mechanical traps: currency lives in an XML attribute, and decimal precision is a property of the currency rather than the schema. Both pass every test you run in a single-currency environment and both fail on the first foreign payment.

Next: charges, DEBT, CRED, and SHAR. 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, FX, Functional Analysis