ISO 20022 Charges: DEBT, CRED, SHAR, and the ChrgsInf Block

ChrgBr is an instruction to every agent in the chain about where its own fee comes from, not a fee schedule. DEBT obliges the beneficiary to receive the full amount. CRED and SHAR allow deduction from the principal. SLEV defers to the scheme, and in SEPA that means full value to the beneficiary. ChrgsInf records who actually took what, and its absence is why short payments become unexplainable.

The previous article ended on a customer who instructed 10,000.00 EUR and whose beneficiary received 9,987.40 EUR, with no currency conversion involved. The 12.60 was a correspondent’s fee, correctly taken and correctly recorded.

Whether that was acceptable depends entirely on one four-letter code. This is the charges article in the field-by-field track of The ISO 20022 Reference, following amounts and FX.

What does the charge bearer actually instruct?

ChrgBr is mandatory in a pacs.008 and takes one of four values. Each is an instruction that binds every agent that touches the payment, not just the originating bank.

Code	Name	What each agent must do	Beneficiary receives
DEBT	Borne by debtor	Do not deduct. Bill the debtor’s side separately	The full instructed amount
CRED	Borne by creditor	Deduct your charge from the amount passing through	Less than instructed
SHAR	Shared	Debtor pays its own agent; others may deduct	Usually less than instructed
SLEV	Following service level	Apply the scheme rulebook’s charging rules	Depends on the scheme

The framing that makes this click: the charge bearer does not describe a price, it describes where the money for the fee comes from. Two banks can charge identical fees and produce completely different beneficiary amounts depending on this code.

DEBT: the expensive promise

DEBT means the beneficiary gets every cent of the instructed amount. No agent in the chain may reduce the principal.

That is a strong obligation, and it is why banks rarely offer it casually. The debtor agent is promising to cover fees that will be charged by correspondents it does not control, on a route it may not fully know in advance. Most institutions handle this by pricing DEBT as a distinct guaranteed-full-value product with a premium, by pre-agreeing fees with their correspondents, or by restricting it to certain corridors.

The analyst consequence: if your product offers DEBT, somebody must own the question of what happens when a correspondent deducts anyway. That is a scheme breach and a customer-facing failure at the same time, and the handling is a business decision. Usually it ends in the debtor agent making the beneficiary whole and raising an investigation with the correspondent, which needs a process, not just an error message.

CRED and SHAR: deduction permitted

Under CRED, charges come out of the payment. The beneficiary receives the instructed amount minus whatever the chain took. The debtor’s cost is predictable; the beneficiary’s receipt is not.

SHAR is the common default in correspondent banking and the source of most confusion. The debtor pays its own bank’s charges directly. Everything beyond that, intermediaries and the creditor agent, may deduct from the principal. So the debtor has a predictable cost, and the beneficiary absorbs a variable amount that depends on how many correspondents the payment passed through.

This is precisely the mechanism behind the classic complaint: “I sent 10,000, they received 9,987.40, nobody told me.” Nothing was wrong. The debtor chose SHAR, the payment routed through one intermediary, and the intermediary took its fee. The failure is in disclosure, not in processing, which makes it an analyst problem rather than a developer problem.

The specification question to force early: does your front end tell the customer that the beneficiary may receive less under SHAR? If it does not, you are building a complaint pipeline.

SLEV: the scheme decides

SLEV means the charging rules come from the service level or scheme governing the payment, not from the code itself.

This matters most in SEPA, where SLEV is the only permitted charge bearer and the rulebook requires that the beneficiary receives the full amount, with each party charged separately by its own bank. In effect, SEPA mandates a behavior closer to DEBT than to SHAR.

Teams that treat SLEV as “basically SHAR” therefore build the wrong arithmetic: they allow deduction on a scheme that forbids it, and the beneficiary receives short on payments where the rulebook guarantees full value. It is a customer-visible defect, it is a compliance breach, and it is entirely avoidable by reading the rulebook layer rather than the code list. SEPA Credit Transfer covers that layer, and it is the same “four layers decide the net rule” problem as reading a usage guideline.

ChrgsInf: the audit trail that explains everything

ChrgsInf is a repeating block. Each occurrence records a charge that was actually taken:

• Amt: the amount, with its currency as an attribute, exactly as in the amount fields.
• Agt: the agent that took it.
• Plus, where the guideline supports it, a type code describing the nature of the charge.

This block is the difference between a payment you can explain and one you cannot. Walk a three-hop SHAR payment:

Bank A sends       IntrBkSttlmAmt 10000.00 EUR   ChrgsInf: (empty)
Bank B deducts 12.60
Bank B sends       IntrBkSttlmAmt  9987.40 EUR   ChrgsInf: 12.60 EUR, Bank B
Bank C credits      9987.40 EUR

With ChrgsInf populated, operations answers the customer’s question in fifteen seconds. Without it, the investigation becomes a message to a correspondent and a three-day wait, and the same question arrives again next week.

So make this a hard requirement in your own specification: any agent in your institution that deducts a charge must add a ChrgsInf entry naming itself and the amount. It costs nothing to implement and it removes an entire category of investigation. It also gives your reconciliation a way to prove the arithmetic: settlement amount in, minus the sum of charges added, equals settlement amount out.

What to specify and what to test

Five specification statements:

1. Which charge bearers your product supports per corridor and per scheme, and which is the default.
2. What your systems do on each value: when they deduct, how much, and from which amount.
3. The disclosure rule. What the customer is told about possible deductions, and where.
4. The exception path when a payment arrives with a deduction that the charge bearer forbade.
5. That ChrgsInf is mandatory output whenever you deduct.

Test conditions, which is where charges get interesting because the arithmetic compounds across hops:

• One case per charge bearer value, end to end across at least three hops, asserting the exact beneficiary amount.
• DEBT with an intermediary that attempts a deduction: the exception must fire.
• SLEV on a SEPA payment: the beneficiary must receive the full amount.
• SHAR with two intermediaries each deducting: two ChrgsInf entries, and the arithmetic must reconcile.
• Charges in a currency different from the settlement currency, which is legal and routinely mishandled.
• A deduction that would take the settlement amount to zero or below, which must be refused.

That last one sounds theoretical. It is not: small-value payments through multi-hop SHAR chains genuinely can be consumed by fees, and a system with no floor check will happily settle a zero. Derive the whole set with the six-source method from how to write pacs.008 test cases.

The takeaway

ChrgBr binds every agent in the chain, not just the sender. DEBT guarantees the beneficiary full value and obliges the debtor agent to cover a chain it does not control. CRED and SHAR permit deduction from the principal, which is why beneficiaries receive less and customers complain. SLEV hands the decision to the scheme, and in SEPA that means full value, so treating it as shared is a real defect.

ChrgsInf is the field that turns a short payment from a mystery into a line item. Make populating it non-negotiable for any agent of yours that deducts, and make the sum of charges reconcile against the difference in settlement amounts.

Next: purpose codes and category purpose, the fields that quietly drive routing, reporting, and tax treatment. 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, Charges