How to Identify Credit and Debit Entries in a CAMT.053 Statement

Banks and companies use CAMT.053 statements to understand incoming and outgoing payments. Many users still struggle with camt.053 credit and debit identification, especially when the XML looks confusing. The good news is that the rule is simple. There is only one field that tells you whether the entry is a credit or a debit.

The One Field That Defines Everything

Inside each <Ntry> block, ISO 20022 provides:

`<CdtDbtInd>`

This field completes your camt.053 credit and debit identification:

CRDT means a credit entry
DBIT means a debit entry

It is the official indicator.
The amount does not carry a plus or minus sign, so you cannot judge direction from the amount alone.

Example in Simple English

A typical CAMT.053 entry looks like this:

<Ntry>
   <Amt Ccy="USD">500.00</Amt>
   <CdtDbtInd>CRDT</CdtDbtInd>
   <BookgDt>
      <Dt>2025-11-29</Dt>
   </BookgDt>
   <ValDt>
      <Dt>2025-11-29</Dt>
   </ValDt>
</Ntry>

Here:

The amount is USD 500.00
CRDT tells you money came into your account

For a debit entry, the same block will show:

<CdtDbtInd>DBIT</CdtDbtInd>

This means money left your account.

Why Amount Alone Does Not Help

Some users expect a “minus” sign for debits. In ISO 20022, the amount in CAMT.053 is always positive.
The purpose of the camt.053 credit and debit identification field is to remove any guesswork.

Batch Entries: A Common Confusion

Sometimes one entry contains several underlying transactions.
Even then, the parent entry uses a single indicator:

Parent: <CdtDbtInd>DBIT</CdtDbtInd>
Child transactions may show their own indicators in <TxDtls>

The statement total always follows the parent <Ntry> direction.

Where You See This in Bank Systems

Most banking interfaces simply convert:

CRDT → Credit
DBIT → Debit

Your core banking system reads the XML and shows the direction in your internal statement screen.

For official examples, see SWIFT’s ISO 20022 documentation:
https://www.swift.com/standards/iso-20022

pacs.008 Fields Explained in Simple English

When money is sent across borders under ISO 20022, banks use a structured message called pacs.008. In this article, we’ll have the pacs.008 fields explained for better understanding. This message is the ISO 20022 replacement for the old MT103 and is used for customer-to-customer international payments.

A pacs.008 contains two main parts:

Group Header – Basic information
Credit Transfer Transaction Information – The actual details of one payment

This post explains the second part, using simple language and clear examples anyone can understand.

Credit Transfer Transaction Information (Section B)

This section describes everything about one single payment:

Who is sending money
Who is receiving money
How much
Why
Which banks are involved
Who pays charges
How the transaction will settle

Below is a table showing each ISO 20022 field, a simple description, and a clear example.

Table explaining pacs.008 fields with descriptions and examples including settlement method.

Understanding Each Field (Plain English)

1. — Instruction Identification

A reference your bank creates to identify the payment internally.
Example: PKBR-2025-11-22-001

2. — End-to-End Identification

A reference that stays the same from sender to receiver.
Example: E2E-PKBK-908877

3. — Unique End-to-End Transaction Reference

A mandatory gpi tracking number used like a parcel tracking code.
Example: 55c1ca88-89f3-4e62-b3f5-112233445566

4. — Instructed Amount

Money the sender wants to transfer.
Example: USD 5,000.00

5. — Debtor

The customer sending the money.
Example: ABC Importers Ltd, Karachi

6. — Debtor Account

Sender’s account number or IBAN.
Example: PK49FAKE0000000123456789

7. — Debtor Agent

The sender’s bank.
Example: PKBAPKKXXXX

8. — Creditor

The customer receiving the money.
Example: Global Machinery GmbH, Munich

9. — Creditor Account

Receiver’s account number.
Example: 987654321

10. — Creditor Agent

The beneficiary’s bank.
Example: DEUTDEMMXXX

11. — Purpose Code

Reason for payment.
Example: CORT (Trade settlement)

12. — Remittance Information

What the payment is for.

Unstructured (simple text, 140 characters)
Structured (detailed invoice info, up to 9,000 characters)

Example:
Invoice 1217 for industrial pump

13. — Charge Bearer

Who pays the fees?

Code	Meaning
SHAR	Shared charges
DEBT	Sender pays all
CRED	Receiver pays all
SLEV	SEPA rule

Example: SHAR

14. — Settlement Information (NEW SECTION ADDED)

Settlement Information tells how the payment will be settled between banks.

The most important element inside this block is:

— Settlement Method

This defines how the payment moves through the banking system.

ISO 20022 supports four values:

Code	Meaning
CLRG	Clearing system
COVE	Cover method
INDA	Instructed agent
INGA	Instructing agent

Example Settlement Method:

INDA

This means the payment will settle directly through the instructed agent (the Creditor Agent).

This field is critical because it tells the receiving bank how to expect the funds.

Complete Real-World Example

A business in Karachi pays USD 5,000 to a supplier in Munich:

InstrId: PKBR-2025-11-22-001
EndToEndId: E2E-PKBK-908877
UETR: 55c1ca88-89f3-4e62-b3f5-112233445566
InstdAmt: USD 5,000.00
Dbtr: ABC Importers Ltd, Karachi
DbtrAcct: PK49FAKE0000000123456789
DbtrAgt: PKBAPKKXXXX
Cdtr: Global Machinery GmbH, Munich
CdtrAcct: 987654321
CdtrAgt: DEUTDEMMXXX
Purp: CORT
ChrgBr: SHAR
RmtInf: Invoice 1217 for industrial pump
SttlmMtd: INDA

This is exactly how the transaction appears inside a pacs.008 message.

SWIFT MX Message Terms Explained with Examples for ISO20022 Payments

ISO20022 MX has become the global standard for cross-border payments. But the system also produces long technical logs filled with fields most bankers see daily—yet rarely understand. This guide breaks down the most common SWIFT MX message terms with safe, clean, fictional examples.

1. Requestor DN (Distinguished Name)

The Requestor DN identifies the bank that initiates the MX message on the SWIFT network.

Example (fictional):
ou=cf-bnklpkka, o=swift

Breakdown:

bnklpkka → BIC of the sending bank (fictional)
ou= → organisational unit
o=swift → SWIFT domain

Meaning:
The message was pushed into SWIFT by the institution coded BNKLPKKA.

2. Responder DN

Shows which institution processed or received the message.

Example (fictional):
ou=cf-qtrfpkka, o=swift

Meaning:
The responding bank is coded QTRFPKKA (fictional BIC).

This field is helpful in reconciliation and payment investigations.

3. Service Name (finplus)

Indicates which SWIFT network service handled the message.

Example:
Service Name: finplus

Usage:

finplus → ISO20022 MX service
swiftnet → general messaging
retailplus → retail connections (fictional)

FINplus is now mandatory for all cross-border ISO20022 traffic.

4. Non-Repudiation Indicator

Shows whether SWIFT Non-Repudiation Service (NRS) is applied.

Example:
Non-repudiation Indicator: False

Meaning:
The message is not signed with non-repudiation cryptographic evidence.

If this were True, SWIFT could prove the origin of the message in compliance investigations.

5. SWIFT Reference (Generated by SWIFT)

A unique tracking ID created by SWIFT FINplus.

Example (fictional & safe):
swi0203027-09-18T14:22:45.983472_5598217Z

Breakdown:

2027-09-18 → date of processing
T14:22:45.983472 → timestamp
_5598217Z → internal SWIFT sequence

This reference is used when tracing or recalling payments.

6. SWIFT Request Reference (Generated by the sending bank)

Unlike the SWIFT reference, this ID is generated by the bank’s own interface.

Example (fictional):
SNL5824420270918T142245B910_8821735

Purpose:

Internal reconciliation
Investigations of stuck or rejected messages
Reference between core banking and SWIFT gateway

Think of it as the “local tracking number” before SWIFT assigns its own.

7. CBT Reference (Cross-Border Transfer Reference)

This is the ID used inside the bank’s internal systems, usually a UUID.

Example (fictional):
7fa91372-89c1-4c61-a4c9-902d51b4e8dd

Used by:

AML screening
Treasury settlement
Payment repair teams
Nostro reconciliation

Every bank generates its own long-form internal identifiers.

8. Store-and-Forward Input Time

The moment the message entered SWIFT’s Store-and-Forward queue.

Example (fictional):
2027-09-18T14:22:45

This timestamp is essential for:

cut-off time disputes
SLA monitoring
operational reconciliation

9. Signing DN (Certificate Identity)

This identifies the certificate that signs the MX message.

Example (fictional):
cn=mxusr05, o=bnklpkka, o=swift

Meaning:

mxusr05 → SWIFT user/application signing the message
bnklpkka → fictional sending bank
o=swift → SWIFT network

Digital signatures ensure message security and authenticity.

10. Message Header (ISO20022 Type)

Identifies the MX message schema used.

Example:
pacs.009.001.10

Explanation:

pacs.009 → Financial Institution Credit Transfer
001.10 → version 10 of the schema

Other common headers:

pacs.008 → Customer Credit Transfer
pacs.004 → Return
camt.029 → Investigation response
camt.056 → Cancellation request

11. AppHdr Block

Displayed as:
<AppHdr xmlns="urn:iso:std:iso:20022:tech:xsd:head.001.001.02">

Contains:

Sender BIC
Recipient BIC
Business Message Identifier
Definition Identifier
Creation timestamp

It is the “envelope” that carries routing and identification data.

Conclusion

Understanding SWIFT MX message terms helps operations officers, compliance teams, treasury staff, and payment processors handle ISO20022 transactions with confidence. Each term in the FINplus log has a specific purpose that supports security, traceability, and accurate settlement across the global financial network.