Akande Simpa
Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs Comprehensive Security Partner (CSP)

ISO 20022: XML External Entity (XXE) vulnerabilities

ISO 20022 messages use an XML schema format (pacs.008 for credit transfers, camt.053 for bank statements). If the XML parser in the bank's processing engine is not configured securely, it may resolve external entity references inside incoming payment messages. This leads to XML External Entity (XXE) injection, allowing attackers to read internal server files or trigger SSRF:

<!-- Malicious pacs.008 XML payload containing XXE -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Document [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.08">
  <FIToFICstmrCdtTrf>
    <GrpHdr>
      <MsgId>&xxe;</MsgId> <!-- Server evaluates file contents and returns them in logs or responses -->
    </GrpHdr>
  </FIToFICstmrCdtTrf>
</Document>

The Fix: Disable External Entity Resolution (DTD) in your XML parser configuration. In Java DOM or SAX parsers, explicitly set disallow-doctype-decl to true:

// SECURE XML Parser Factory configuration
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);

Sanction and AML bypass via character manipulation

ISO 20022 messages carry extensive structural data about the sender and recipient. Banks run these fields through automated sanction and Anti-Money Laundering (AML) list checkers. Attackers attempt to bypass these filters by substituting visually identical characters (homoglyphs) or injecting non-printable control characters into the recipient name field (e.g., placing zero-width spaces in "MOHAMMAD"). We audit your string normalization engines to ensure they strip control characters and normalize Unicode characters before screening.

SWIFT CSP secure zone isolation

The SWIFT Customer Security Programme (CSP) establishes the SWIFT Secure Zone: an isolated network segment containing the SWIFT Alliance Gateway and related messaging terminals. We perform penetration testing against this zone boundary, checking for: firewall configuration leaks, unauthorized remote access endpoints, and missing network segregation from the general corporate active directory domain.

Example finding

XXE injection in XML transaction processor

A pacs.008 message with an external entity can make an unsafe XML parser read a local test file or call an internal URL. Disable DTDs and external entities, enforce the expected schema, and return a fixed error with no parser detail.

Build a safe ISO 20022 test pack

Use synthetic accounts and approved message samples. Create one valid message for each supported type, then change one field at a time: account, amount, currency, agent, character set, duplicate ID, timestamp, signature, and message order. The parser must reject external entities, unknown fields, invalid schemas, duplicate transactions, and broken signatures before any posting step.

Keep the message type, schema version, redacted request, validation error, transaction ID, queue record, and ledger result. One accepted malformed message is enough to stop release. Review the wider API security testing scope for authorization and replay tests.

Migrating to ISO 20022 or preparing for SWIFT CSP assessment? Schedule a security audit.

Book a SWIFT / ISO 20022 Audit

Frequently asked questions

What is the ISO 20022 migration security risk?

ISO 20022 replaces legacy MT message formats with structured XML (MX) messages. Parsing these complex XML schemas introduces vulnerabilities like XML External Entity (XXE) injection and schema validation bypasses if parsers are not hardened.

How does the SWIFT Customer Security Programme (CSP) apply to bank audits?

SWIFT CSP defines mandatory security controls for SWIFT users, covering secure zone definition, operating system hardening, credential protection, and incident response readiness.

What is transaction structuring in financial messaging?

Structuring involves manipulating transaction parameters (such as breaking up large payments into smaller amounts or modifying sender fields) to bypass anti-money laundering (AML) and sanction filters.

Related reading

Blog: ISO 20022 bank security · NIBSS downtime race conditions · API leaks

Services: Penetration testing · Secure architecture review