pacs.008 FI-to-FI credit transfer

EVERY ANNOTATED FIELD

GrpHdr/MsgId Message identification — mandatory

A unique reference for this message, assigned by the instructing agent. It changes at every hop; end-to-end references live at transaction level.

Point-to-point duplicate detection keys on MsgId between adjacent agents. It is not the reference to quote to the customer.

⚠ Confusing MsgId with EndToEndId in reconciliation logic breaks matching as soon as a payment crosses more than one hop.

GrpHdr/CreDtTm Creation date and time — mandatory

When this message was created — a timestamp for the message, distinct from the settlement date of the payment.

GrpHdr/NbOfTxs Number of transactions — mandatory

How many credit transfer transactions the message contains.

The base standard allows batches, but usage guidelines differ: the correspondent-banking usage constrains a message to a single transaction, while some market infrastructures permit more. Check the guideline in force.

GrpHdr/SttlmInf/SttlmMtd Settlement method — mandatory

How the interbank settlement of this payment happens: INDA (settled on an account the instructed agent services), INGA (on an account the instructing agent services), CLRG (through a clearing system), or COVE (through a separate cover payment).

COVE is the signal that a pacs.009 COV is travelling separately to move the funds — the receiving bank should expect to match the two.

⚠ A settlement method that contradicts the actual account relationship between the two agents causes settlement fails and investigations.

CdtTrfTxInf/PmtId/EndToEndId End-to-end identification — mandatory

The reference assigned by the original instructing party. It must travel unchanged through every agent to the creditor.

This is the reference that survives from pain.001 through pacs.008 to the creditor's statement, and the one echoed back in pacs.002, pacs.004, and camt.056.

⚠ Agents that overwrite EndToEndId with their own references destroy end-to-end reconciliation for everyone downstream.

CdtTrfTxInf/PmtId/UETR Unique end-to-end transaction reference — mandatory

A globally unique identifier (a UUID) for the payment, used to track it across the whole chain regardless of how many hops it takes.

The Swift gpi Tracker follows payments by UETR. Every agent must pass it on unchanged; a payment's status queries, cancellations, and confirmations all key on it.

⚠ Generating a fresh UETR at an intermediate hop silently forks the tracking history — the payment looks stuck to the originator and orphaned to the tracker.

CdtTrfTxInf/IntrBkSttlmAmt Interbank settlement amount — mandatory

The amount and currency that actually settles between the two agents on this leg — after any deducted charges, not necessarily what the customer instructed.

The originally instructed amount can travel separately in InstdAmt. When the two differ, charges or currency conversion explain the gap — and receiving banks check that arithmetic.

⚠ Treating the settlement amount as the customer's instructed amount misstates expected credits and triggers beneficiary complaints.

CdtTrfTxInf/IntrBkSttlmDt Interbank settlement date — mandatory

The date the amount settles between the agents — the interbank value date of this leg.

Liquidity and nostro reconciliation work off this date. Cut-off times decide whether the requested date is achievable on each leg.

CdtTrfTxInf/ChrgBr Charge bearer — mandatory

Who pays the banks' fees: DEBT (debtor pays all), CRED (creditor pays all), SHAR (each side pays its own), or SLEV (whatever the scheme's service level prescribes).

Schemes restrict the choice — the SEPA credit transfer implementation guidelines prescribe SLEV, while correspondent-banking usage works mainly with DEBT and SHAR.

⚠ Sending a charge-bearer code the destination scheme does not allow is a classic reject reason at the entry point to that scheme.

CdtTrfTxInf/Dbtr Debtor — mandatory

The customer the payment is from, with name and address — structured elements for street, town, and country exist and are preferred.

This is prime sanctions-screening material at every bank in the chain. Structured, complete originator data is also a payment-transparency expectation, not just a formatting preference.

⚠ Address text dumped into unstructured lines — often the residue of MT-to-MX translation — drives screening false positives and repair queues.

CdtTrfTxInf/DbtrAgt Debtor agent — mandatory

The debtor's PSP — the bank that debited the customer and stands at the start of the interbank chain, normally identified by a BIC (Business Identifier Code).

CdtTrfTxInf/PrvsInstgAgt1 Previous instructing agent 1 — optional

The agent that instructed the current sender on the immediately preceding leg — it records where the payment came from. Agents 2 and 3 (and their accounts) preserve more of the routing history when the chain is longer.

Previous instructing agents look backward (where the payment has been); intermediary agents look forward (where it still has to go).

CdtTrfTxInf/IntrmyAgt1 Intermediary agent 1 — optional

The first intermediary (correspondent) bank between the debtor agent and the creditor agent. Intermediary agents 2 and 3, each with an optional account element, extend the chain when more correspondents are involved.

Each intermediary screens independently and can hold or return; more hops means more places a payment can stall.

CdtTrfTxInf/CdtrAgt Creditor agent — mandatory

The creditor's PSP — the bank that will credit the beneficiary at the end of the chain.

⚠ A creditor agent that is unreachable on the chosen rail forces rerouting or returns; reachability checks belong before sending, not after.

CdtTrfTxInf/Cdtr Creditor — mandatory

The customer being paid, with name and address.

Beneficiary name quality matters twice: for screening, and for name-checking services that compare the name against the account before crediting.

⚠ A name that does not match the account holder at the creditor agent leads to delay, repair, or return depending on local practice.

CdtTrfTxInf/Purp/Cd Purpose code — optional

The reason for the payment as a 4-letter code (e.g. SUPP), carried from debtor to creditor for the creditor's benefit; it is not used by the banks to route.

Distinct from category purpose (bank-facing) in the payment-type information — see the code reference for both lists.

CdtTrfTxInf/RmtInf Remittance information — optional

What the payment is for — unstructured text (Ustrd) or structured references (Strd) such as invoice numbers, passed through to the creditor.

ISO 20022 allows far richer remittance data than the four 35-character lines of the MT103's field 70 — which is exactly what truncates when messages are translated back to MT.

⚠ Remittance text is screened. Free text naming embargoed places, vessels, or goods stops otherwise clean payments.