MT101 vs Pain.001: A Practical Guide for Treasury Teams

In my previous article (link here), I explained the difference between MT940 and CAMT.053, in other words, how you see the cash. Now it’s time to talk about how you move it.

This article breaks down MT101 vs. Pain.001 — the old vs. the new way of sending payments — and what this migration actually means for treasury.
You’ll see:

what you really gain
what needs to change in your ERP
and why it’s not as “plug & play” as the sales decks promise, but also not as scary as you think.

Let’s get into it:

Understanding the Migration: MT101 vs Pain.001

What actually changes when you move from legacy SWIFT to structured XML?

The Real Difference

MT101 (the old way):

Fixed 35-character lines
Limited payment details
Manual interpretation required
Bank-specific variations that cause headaches

Example:

:20:PAYREF12345
:23E:INST
:50K:/RO49AAAA1B31007593840000
COMPANY NAME LIMITED
:59:/RO49BBBB1B31007593840001
SUPPLIER NAME SRL
:70:/INV/2024001//SERVICES FEB
:32A:240315RON1000,00

Pain.001 (the new way):

Structured XML format
Rich payment data including purpose codes, debtor/creditor details
Based on ISO 20022 standard, but each bank may implement it differently
Structured and machine-readable, enabling automation when integrated with compatible systems

Example:

<PmtInf>
  <PmtInfId>BATCH20240315001</PmtInfId>
  <PmtMtd>TRF</PmtMtd>
  <ReqdExctnDt>2024-03-15</ReqdExctnDt>
  <Dbtr>
    <Nm>COMPANY NAME LIMITED</Nm>
  </Dbtr>
  <DbtrAcct>
    <Id>
      <IBAN>RO49AAAA1B31007593840000</IBAN>
    </Id>
  </DbtrAcct>
  <CdtTrfTxInf>
    <PmtId>
      <InstrId>PAYREF12345</InstrId>
      <EndToEndId>INV2024001</EndToEndId>
    </PmtId>
    <Amt>
      <InstdAmt Ccy="RON">1000.00</InstdAmt>
    </Amt>
    <Cdtr>
      <Nm>SUPPLIER NAME SRL</Nm>
    </Cdtr>
    <CdtrAcct>
      <Id>
        <IBAN>RO49BBBB1B31007593840001</IBAN>
      </Id>
    </CdtrAcct>
    <RmtInf>
      <Strd>
        <RfrdDocInf>
          <Tp><CdOrPrtry><Cd>CINV</Cd></CdOrPrtry></Tp>
          <Nb>INV2024001</Nb>
          <RltdDt>2024-02-28</RltdDt>
        </RfrdDocInf>
      </Strd>
      <Ustrd>Payment for February services</Ustrd>
    </RmtInf>
  </CdtTrfTxInf>
</PmtInf>

Detailed Comparison

Here’s a side-by-side view of what really sets them apart:

Criteria	MT101	Pain.001
Format Type	SWIFT FIN (plain text)	ISO 20022 XML (structured)
Data Structure	Flat, fixed tags (e.g., :50K:, :59:)	Hierarchical XML with rich tagging
Remittance Data	Limited (max 4×35 chars in :70:)	Structured, supports invoices & references
Validation	Basic format checks	Rich validation with business rules
Automation Readiness	Requires manual parsing	Machine-readable, automation-friendly
Bank Adoption	Legacy standard, being phased out	Increasingly adopted, especially in SEPA and EU regulatory environments
File Size	Compact	3-4x larger than MT101
Human-readable	Yes	No (requires XML viewer)
Automation-ready	No	Yes
Rich payment data	No	Yes
Standardized structure	No	Yes (with local/bank-specific implementation differences)
Future-proof	No	Yes (Designed for long-term use and alignment with global standards ISO 20022).

Operational Benefits at a Glance

Now let’s look at what this means in day-to-day operations:

Task	MT101	Pain.001
Payment setup	Manual field entry	Can be automated if ERP is configured to generate Pain.001
Reference matching	Difficult truncation issues	Full invoice references
Status tracking	Limited visibility	Improved status visibility if pain.002 acknowledgments are supported by the bank
Error handling	Manual investigation	Structured error codes available via pain.002, if supported by bank
Compliance reporting	Manual compilation	Automated extraction possible if ERP and reporting tools support XML parsing

Pain.001 Implementation Roadmap

Let’s move from theory to practice. Here’s what a real-world Pain.001 migration actually looks like, broken down step by step.

Phase 1: Assessment & Planning

-> Current State Analysis

Action Items:

Payment Volume Audit: Document current MT101 message volumes by bank
ERP Integration Review: Assess current payment file generation process
Bank Relationship Mapping: Identify primary payment channels and formats

Key Questions to Answer:

What payment types do we process? (domestic, SEPA, international)
Which banks support Pain.001 and what are their timelines?
How does our ERP currently generate payment files?

-> Technology Evaluation

System Readiness Assessment:

ERP Capability Check: Verify Pain.001 generation capabilities
Bank Connectivity Review: Assess current file transmission methods
Integration Requirements: Identify middleware or API needs

Deliverable: Migration readiness report with timeline and budget

Phase 2: Solution Selection & Setup

-> Vendor & Bank Coordination

Bank Engagement:

Request Pain.001 specifications from each bank
Negotiate implementation timelines and testing schedules
Understand bank-specific requirements and proprietary extensions

Technology Partner Selection:

Evaluate ERP vendor Pain.001 capabilities
Consider middleware solutions if needed
Assess cloud-based treasury platforms

-> System Configuration

Pain.001 Template Creation:

Design payment message templates for each payment type
Map existing MT101 fields to Pain.001 structure
Create enhanced remittance data formats for better reconciliation

Integration Setup:

Configure ERP to generate Pain.001 files
Set up automated validation rules
Set up secure channels (e.g., SFTP or APIs) for sending payment files

Deliverable: Configured systems ready for testing

Phase 3: Testing & Go-Live

-> Testing Phase

Bank Connectivity Testing:

Execute test payments with each bank using Pain.001 format
Validate message formatting and field population
Test exception scenarios and error handling

End-to-End Testing:

Process test payments through complete workflow
Verify status tracking and acknowledgment processing
Test integration with accounting and reconciliation systems

-> Production Rollout

Phased Go-Live Strategy:

Start with low-risk, high-volume payment types (supplier payments)
Gradually migrate specialized payments (payroll, tax, international)
Run parallel processing for 30 days minimum

Training & Documentation:

Conduct user training on new Pain.001 workflows
Create operational procedures and troubleshooting guides
Establish support escalation procedures

Deliverable: Full Pain.001 production capability with parallel MT101 backup

Technology Solutions

Depending on your ERP, the road to Pain.001 can be smooth or full of workarounds. Here’s what to expect with the most common platforms.

ERP Enhancement Options

For SAP Users:

Payment Engine Enhancement: Configure Pain.001 formats in FBZP transaction
Implementation: Activate ISO 20022 payment formats through standard customization
Timeline: Typical range: 2–4 months depending on complexity.

For Microsoft Dynamics Users:

Electronic Payments: Configure Pain.001 export formats in Cash and Bank Management
Implementation: Use standard payment format setup with XML configuration
Timeline: Typical range: 2–4 months depending on complexity.

For Oracle ERP Users:

Payments Module: Built-in Pain.001 format generation capabilities
Implementation: Configure through Payment Administrator setup
Timeline: Typical range: 2–4 months depending on complexity.

For Other ERP Systems:

Middleware Solutions: Consider middleware to transform existing formats into Pain.001, if ERP lacks native support.
File-Based Integration: Transform existing payment files to Pain.001 format
Timeline: Typical range: 2–4 months depending on complexity.

Understanding Pain.001 Message Structure

To really work with Pain.001, you need to understand how the message is built. Let’s break down the key components that matter in treasury.

Payment Information (<PmtInf>)
The batch header. It defines who’s paying, when, how, and from which account.
All payments inside this block share the same characteristics (execution date, method, etc.).

Credit Transfer Details (<CdtTrfTxInf>)
Each individual payment within the batch. Includes the amount, currency, beneficiary details, and references.

Debtor (<Dbtr> / <DbtrAcct>)
The entity sending the money — typically your company. Specifies the payer name and IBAN.

Creditor (<Cdtr> / <CdtrAcct>)
The recipient of the payment — supplier, employee, tax authority, etc. Includes their name and IBAN.

Remittance Information (<RmtInf>)
Supports both structured and unstructured data. Used for invoice numbers, PO references, or free-text notes like “February services”.
Helps with automatic reconciliation if your system matches it properly.

Payment Purpose (<Purp>)
A short code (like SALA, TREA, TAXS) explaining what the payment is for. Useful for categorization, compliance, and analytics.

Charge Bearer (<ChrgBr>)
Defines who pays the fees — you (DEBT), the beneficiary (CRED), shared (SHAR), or as per SEPA rules (SLEV). Critical for international payments.

Service Level (<SvcLvl>)
Specifies how the payment should be handled — e.g. SEPA (standard), SDVA (same-day), or NURG (normal urgency).

Essential Fields for Treasury:

Field	Purpose	Benefit
`<InstrId>`	Unique payment identifier	Enables precise tracking and reconciliation
`<EndToEndId>`	End-to-end reference	Links payment to invoice/purchase order
`<RmtInf>`	Remittance information	Structured invoice references for auto-reconciliation
`<Purp>`	Payment purpose	Enables automated categorization and reporting
`<Dbtr>` / `<DbtrAcct>`	Debtor name and account	Identifies the paying entity and originating IBAN
`<Cdtr>` / `<CdtrAcct>`	Creditor name and account	Identifies the beneficiary and receiving IBAN
`<ChrgBr>`	Charge bearer	Specifies who covers transaction fees (e.g. SHAR, DEBT)
`<SvcLvl>`	Service level	Indicates processing type (e.g. SEPA, URGENT, STANDARD)

Payment Status and Acknowledgments

Pain.002 – Status Reports: After sending a Pain.001 file, your bank replies with a Pain.002 message. It tells you which payments were accepted, rejected, or still pending.
These acknowledgments are key for automation, exception handling, and audit trails.

Status Codes to Monitor:

ACCP – Accepted: Payment instruction accepted by bank
RJCT – Rejected: Payment rejected with reason codes
PDNG – Pending: Payment awaiting further processing
ACSC – Accepted Settlement Completed: Payment successfully processed

Pro tip: Always process and store Pain.002 responses automatically, don’t rely on bank portals or email confirmations.

Common Pain.002 Rejection Codes

Code	Meaning	Typical Cause / Action Required	Retry Possible?
`AG01`	Transaction forbidden	Account blocked or restricted for this operation	Manual intervention
`AM09`	Amount exceeds limit	Daily/payment limit exceeded	After correction
`AC04`	Invalid account number	IBAN incorrect or closed	Manual intervention
`RC01`	Invalid creditor BIC	Invalid or missing BIC code	If corrected
`FF01`	Invalid file format	Pain.001 message incorrectly structured	After fixing format
`BE04`	Duplicate message	Same payment ID used twice	Investigate first
`MD06`	Missing or invalid mandatory data	Required field missing or invalid (e.g. execution date)	If completed
`NARR`	Narrative reason provided	Bank provides free-text explanation	Depends on reason

Retry vs. Manual Fix – Quick Guide

Safe to Retry After Fixing

AM09 – Limit exceeded
RC01 – Invalid BIC
FF01 – Format error
MD06 – Missing data

These can be re-submitted automatically after validation rules are applied.

Requires Manual Review

AG01 – Account restrictions
AC04 – Invalid/closed IBAN
BE04 – Duplicate message (risk of double payment)
NARR – Depends entirely on bank’s custom message

Best practice: Build a rejection handling workflow that logs pain.002 codes, maps them to resolution steps, and tags retry-safe errors for automation.

Risk Management & Enhanced Controls

Pain.001 may unlock automation, but without proper controls, you’re just automating risk. Here’s how to build a secure payment setup around it.

Payment Security Framework

Multi-Layer Authentication:

Digital Signatures: PKI-based signing of Pain.001 messages (ensures integrity & non-repudiation)
Dual Authorization: Segregated approval workflows for high-value or high-risk payments
Time-Based Controls: Block payment submission outside working hours (e.g., weekends, nights)

Advanced Validation Rules:

Beneficiary Verification: Real-time screening against sanction and internal blacklists
Amount Limits: Dynamic thresholds by payment type, user role, or beneficiary risk level
Duplicate Detection: Algorithmic checks using hash/fingerprint of key fields (EndToEndId, amount, IBAN)

Operational Risk Controls

Message Validation:

Schema Validation: Pain.001 checked against ISO 20022 XSD
Business Rule Validation: Custom rules (e.g., “no same-day tax payments above X”)
Bank-Specific Validation: Ensure compliance with each bank’s specs before sending

Exception Management:

Automated Rejection Handling: Parses pain.002 and triggers next actions
Repair Workflows: Editable queues with audit trail
Escalation Procedures: Route unresolved exceptions by risk level, value, or time elapsed

Getting the format right is only half the story. Controls like these are what make a payment process truly resilient and audit-ready.

Common Pain.001 Transaction Codes

Now that we’ve covered the controls around payments, let’s take a quick look at the codes that actually define what you’re paying and how it’s processed.

Understanding Purpose Codes

Payment Categories (<Purp><Cd>) – Used to categorize the reason for the payment.

Code	Description	Use Case
`TRAD`	Trade Services	Supplier payments for goods/services
`SALA`	Salary Payment	Payroll processing
`TREA`	Treasury Payment	Intercompany transfers, investments
`TAXS`	Tax Payment	Government tax obligations
`DIVD`	Dividend Payment	Shareholder distributions

Service Level Codes – Define the urgency or clearing type.

SEPA – SEPA Credit Transfer
SDVA – Same Day Value
NURG – Normal Urgency

Bank Transaction Codes (BTC Classifications) – Bank-level classification for reporting and routing.

PMNT-ICDT-ESCT – SEPA Credit Transfer
PMNT-ICDT-XBCT – Cross-Border Credit Transfer
PMNT-ICDT-DMCT – Domestic Credit Transfer

Make sure your ERP or payment engine maps these codes correctly, banks rely on them for routing, fees, and compliance reporting.

Measuring Success: Key Performance Indicators

Once implementation is live, success isn’t just about “it works.” You need KPIs that prove the migration actually added value: operationally, financially, and strategically.

Operational Metrics

Processing Efficiency – some typical targets based on companies with well-integrated ERP/TMS setups:

Payment Setup Time: Reduce from 5 minutes to 30 seconds per payment
Exception Rate: Decrease from 12% to under 2%
Processing Speed: Average payment processing under 90 seconds

Cost Metrics:

Cost per Payment: Track reduction from MT101 baseline
Staff Time Savings: Measure hours reallocated to strategic activities
Bank Fee Optimization: Monitor improved fee structures with structured data

Strategic Value Metrics

Cash Management:

Payment Timing Accuracy: Improved execution date control
Working Capital Optimization: Better payment scheduling and cash flow management
Investment Returns: Enhanced cash forecasting enables improved liquidity management

Risk & Compliance:

Payment Accuracy: Track reduction in processing errors
Compliance Automation: Measure improved regulatory reporting efficiency
Fraud Detection: May support enhanced fraud detection if integrated with proper analytics or monitoring tools

Automating Payment Reconciliation Using Pain.001

Reconciling payments manually wastes time and leads to missed matches. With Pain.001 + Pain.002, you already have the data needed for automation — if you use it right, of course.

Enhanced Reconciliation Process

Reconciling payments can move from manual effort to near real-time automation with the right setup. Here’s how:

Step 1 – Structured Data Extraction

From each Pain.001 message, extract key fields:

<InstrId> – Payment instruction identifier
<EndToEndId> – Invoice/PO reference number
<InstdAmt> – Payment amount and currency
<Cdtr><Nm> – Beneficiary name
<RmtInf> – Structured remittance information

Step 2 – ERP Integration & Matching

Apply the following logic in your ERP or middleware:

Match <EndToEndId> to open AP invoice numbers
Confirm <InstdAmt> matches expected invoice value
Cross-check <Cdtr> with vendor master data
Track the full lifecycle using <InstrId> and payment date

Optional enhancement: log unmatched entries to a reconciliation queue with user alerts.

Step 3 – Automated Status Updates

After submission, monitor Pain.002 acknowledgments:

Parse status codes:
- ACCP – Accepted
- RJCT – Rejected
- PDNG – Pending
- ACSC – Settled
Update payment status automatically in ERP
Generate exception reports for rejected transactions
Trigger retry/resubmission flows where appropriate

Reconciliation Tools by Platform

Not all ERPs are created equal. Some support Pain.001 out of the box, others need a bit of glue logic. Here’s what implementation typically looks like across major platforms:

Platform	Implementation Approach	Estimated Timeline
SAP	Use Bank Communication Management (BCM) with Pain.001 mapping	4–6 weeks
Oracle ERP	Configure Payments Module to generate and process Pain.001	3–5 weeks
Dynamics 365	Implement Electronic Payments with custom reconciliation logic	5–7 weeks
Power Automate	Build flows to parse Pain.001 + integrate with ERP via connectors	2–4 weeks
Custom / Legacy	Develop middleware for file transformation & reconciliation logic	8–12 weeks

Always validate with each platform vendor whether Pain.001 processing includes native support for Pain.002 acknowledgments and reconciliation. Some do not.

Implementation Challenges & Solutions

Pain.001 migration isn’t just a technical lift, it’s also a change management exercise. Here’s what typically goes wrong, and how to avoid it.

Technical Challenges

XML Processing Complexity

Problem: Legacy systems struggle with XML parsing
Solution: Implement middleware or upgrade to modern treasury platforms
Prevention: Evaluate system capabilities early in planning phase

File Size Management

Problem: Pain.001 files are 3-4x larger than MT101
Solution: Upgrade network infrastructure and file storage capacity
Prevention: Plan for increased bandwidth and storage requirements

Bank-Specific Variations

Problem: Different banks implement Pain.001 specifications differently
Solution: Create bank-specific templates and validation rules
Prevention: Request detailed specifications from each bank early

Operational Challenges

User Adoption & Training

Problem: Staff resistance to XML-based formats
Solution: Implement user-friendly interfaces that hide XML complexity
Prevention: Focus training on business benefits rather than technical details

Parallel Processing Complexity

Problem: Running MT101 and Pain.001 simultaneously creates duplication risk
Solution: Implement strict controls and monitoring during transition period
Prevention: Plan detailed cutover procedures with clear milestone checkpoints

Bank Contact Scripts & Templates

Initial Pain.001 Inquiry Email

Subject: Pain.001 Implementation – [Your Company Name] – Account [Account Number]

Dear [Bank Contact],

We are planning to migrate from MT101 to Pain.001 format for our payment instructions on account [Account Number].

Please provide:

Pain.001 implementation timeline and availability
Technical specifications and sample files
Testing environment access and procedures
File transmission options (SFTP, API, Portal)
Bank-specific field requirements or extensions
Implementation support process and contacts
Any additional fees or charges
Parallel processing capabilities during transition

Our current MT101 volume: [X] payments/month Proposed go-live date: [Date]

We would appreciate scheduling a technical discussion to review implementation details.

Best regards, [Your Name], [Title] [Company], [Contact Information]

Technical Specification Request

Follow-up for detailed requirements:

Dear [Technical Contact],

Following our initial inquiry about Pain.001 implementation, please provide:

Technical Documentation:

Pain.001 message specification (XSD schema)
Sample Pain.001 files with various payment types
Validation rules and business logic documentation
Error code reference guide for pain.002 responses

Implementation Details:

Required authentication methods for file transmission
File naming conventions and delivery schedules
Maximum file size and transaction limits per batch
Supported character encoding (UTF-8, ISO-8859-1)

Testing Requirements:

Test environment connectivity details
Test scenarios and validation procedures
Timeline for testing phase completion
Certification requirements for production go-live

This information will help us configure our systems correctly and ensure smooth implementation.

Thank you for your support.

Best regards, [Your Name], [Title]

Implementation Checklists

Don’t just go live. Go live prepared. Use these checklists to avoid surprises and make the Pain.001 rollout smooth.

Pre-Implementation Checklist

Make sure your foundation is solid:

[ ] Bank Pain.001 capabilities confirmed for all payment accounts
[ ] ERP system Pain.001 generation tested in development environment
[ ] Network infrastructure assessed for larger file sizes
[ ] Security protocols established for XML message transmission
[ ] Team training scheduled and materials prepared
[ ] Parallel processing procedures documented
[ ] Bank-specific templates created and validated
[ ] Exception handling procedures defined

Go-Live Checklist

Before you flip the switch:

[ ] All bank connections tested with real Pain.001 messages
[ ] pain.002 acknowledgment processing configured and tested
[ ] File transmission automation implemented and verified
[ ] XML schema validation activated
[ ] Monitoring dashboards configured for payment tracking
[ ] User training completed with hands-on practice
[ ] Support escalation procedures documented and communicated
[ ] Rollback procedures tested and ready if needed

Post-Implementation Monitoring

What to track after go-live:

[ ] Daily payment processing volumes monitored
[ ] Exception rates tracked and analyzed
[ ] pain.002 rejection reasons documented and addressed
[ ] File size and transmission performance measured
[ ] User feedback collected and incorporation planned
[ ] Bank relationship manager feedback sessions scheduled
[ ] Cost savings metrics calculated and reported
[ ] Next phase migration planning initiated

Regulatory & Compliance Benefits

Pain.001 doesn’t just help operations — it’s a quiet compliance enabler. Here’s how it supports regulatory and risk objectives out of the box:

Enhanced Regulatory Reporting:

Area	Benefit
PSD2 Compliance	Rich, structured data supports payment transparency & traceability
AML Screening	Full beneficiary info = better automated screening (incl. address, IBAN)
Tax Reporting	`<Purp>` codes allow tagging of tax-related payments
Audit Trail	XML structure gives granular, traceable records for internal/external audits

Risk Management Improvements:

Control Area	Impact
Sanctions Screening	High-quality data improves name matching and false positive reduction
Fraud Detection	Structured formats allow better anomaly detection rules in analytics
Operational Risk	Less manual work = lower risk of human error or duplicate payments

Future-Proofing Your Payment Operations

API-First Architecture – Ditch the batch mentality. APIs unlock real-time treasury:

Real-Time Connectivity: Instant payment status updates and confirmations
Flexible Integration: Easy connection to new banking partners and services
Scalable Processing: Handle payment volume growth without system limitations

Data-Driven Treasury – Turn payment files into insight engines:

Cash Flow Optimization: Use payment data for better liquidity management
Supplier Analytics: Analyze payment patterns for better supplier relationships
Cost Optimization: Identify opportunities for payment timing and routing improvements

Conclusion: Your Next Steps

Switching from MT101 to Pain.001 isn’t just about compliance or ticking boxes. It’s your chance to clean up the payment mess, automate what should’ve been automated years ago, and finally get visibility into what’s actually happening with your cash.

What to do next:

Audit your ERP – Can it generate real Pain.001? Or do you need middleware?
Talk to your banks – Ask for specs, timelines, and test files. Don’t wait for them to offer.
Spot the gaps – Where are the bottlenecks? Who owns what?
Build a lean taskforce – Treasury + IT + someone who actually gets things done.
Draw the line – Phase the rollout, define success metrics, and set hard deadlines.

What makes it work:

Top-down support – If leadership treats this like “just another IT change,” it’ll stall.
Cross-team ownership – Treasury, AP, IT, audit — everyone should know their part.
Test, break, fix – Then test again. Especially for bank-specific variations.
Train smart – Focus on why it matters, not just where to click.
Pick the right partners – Vendors who speak fluent XML and finance.

The real value isn’t in Pain.001 as a format, it’s in what it unlocks: real automation, better decisions, tighter control. Don’t wait for a regulatory push. Do it because it finally makes sense.

#Enjoy