The reconciliation problem nobody outsources
Every morning, a treasury operations team at a mid-market financial institution opens their inbox and finds statement files from six banking partners. Two sent SWIFT MT940 messages. One sent an ISO 20022 CAMT.053. One sent a proprietary CSV export from their corporate banking portal. One sent a PDF statement because their treasury API is “coming next quarter” and has been for two years. The sixth sent a CAMT.052 intraday report that arrived overnight but covers a different reporting period than the others.
Before a single reconciliation can happen, someone needs to get all six into the same shape. Same field structure. Same timestamp convention. Same debit/credit representation. Same currency handling. Same transaction categorization.
This is not a technology modernization problem. ISO 20022 was supposed to solve it: one standard to rule them all. In practice, ISO 20022 created a seventh format that coexists with the six that were already there. The migration is happening, but it is happening at different speeds across different institutions, different geographies, and different message types. A bank that sends CAMT.053 for account statements still sends MT103 for payment confirmations. A custodian that adopted ISO 20022 for securities settlement still exports position reports as proprietary fixed-width files.
The operations team reconciles across all of them, every day, regardless of format.
SWIFT MT messages: structured but arcane
SWIFT MT messages (MT940, MT950, MT103) remain the backbone of interbank communication for many institutions. They use a field-tagged format where numbered tags encode specific data elements.
The :61: statement line in an MT940 is the densest example. It packs the value date, entry date, debit/credit indicator, amount, transaction type identification code, reference, and supplementary details into a single field with positional parsing rules. A typical :61: line looks like:
:61:2603070307D15000,00FMSCNONREF//BANK-REF-123
This encodes: value date March 7, 2026; entry date March 7; debit; amount 15,000.00; transaction type “MSC” (miscellaneous); customer reference “NONREF”; bank reference “BANK-REF-123.” Extracting these into discrete fields requires positional parsing that understands the MT format specification, including the rules for when sub-fields are optional and how their absence shifts the positions of subsequent sub-fields.
The :86: information to account owner tag is even more variable. Its content is institution-specific. Some banks use it for structured remittance data with sub-fields delimited by slashes. Others use it for free-text descriptions. Some include the counterparty name and account number. Others include internal processing codes that mean nothing outside that bank’s systems. The same tag, in the same message type, carries fundamentally different content depending on the sender.
Parsing MT messages is not technically difficult; the specification is well-documented. The difficulty is that every banking partner’s MT messages have institution-specific conventions layered on top of the standard. The format is standardized. The content is not.
ISO 20022 CAMT: the standard that varies
ISO 20022 was designed to replace SWIFT MT messages with a richer, more structured XML format. CAMT messages (CAMT.052 for intraday reports, CAMT.053 for end-of-day statements, CAMT.054 for debit/credit notifications) provide the account reporting functionality that MT940 and MT950 handle in the legacy world.
The XML structure is deeply nested. A CAMT.053 contains a BkToCstmrStmt (Bank to Customer Statement) element, which contains Stmt (Statement) elements, which contain Ntry (Entry) elements, which contain NtryDtls (Entry Details), which contain TxDtls (Transaction Details), which contain RltdPties (Related Parties), which contain Dbtr (Debtor) and Cdtr (Creditor) elements with their own nested address and identification structures.
A single transaction in a CAMT.053 can span 40 or more XML elements across 6 levels of nesting. Extracting a flat transaction record (date, amount, debit/credit, counterparty name, reference, category) requires navigating this hierarchy and knowing which elements are mandatory, which are optional, and which carry the operationally relevant data versus the metadata.
The promise of ISO 20022 was standardization. The reality is that the standard allows extensive optionality. Two banks sending CAMT.053 messages may populate completely different optional elements. One includes full counterparty address information in the RltdPties section. Another omits it entirely and puts the counterparty name in the AddtlNtryInf (Additional Entry Information) free-text field. A third includes a proprietary Prtry (Proprietary) element with bank-specific codes that are not part of the ISO 20022 standard but are embedded in the standard’s extension mechanism.
The result is that “we both use ISO 20022” does not mean “our data is compatible.” It means the outer container is the same. The content still varies by institution.
Proprietary ledger exports: the format nobody documents
Beyond SWIFT and ISO 20022, many financial partners provide account data through proprietary exports from their banking portals. These are the CSV downloads, Excel reports, and fixed-width files that relationship managers send when the API integration is not ready or when the institution does not support automated statement delivery for that account type.
These exports follow no standard. Column headers are whatever the bank’s development team chose. Date formats are whatever the bank’s locale defaults to. Debit/credit indicators might be positive/negative amounts, separate columns, or a flag field with values like “D”/“C” or “DR”/“CR” or “DEBIT”/“CREDIT.”
A treasury team managing accounts across 15 banking partners might receive proprietary exports from 5 of them. Each export has a different structure. Each requires its own parsing logic. When the bank updates their portal (which they do without notice, because the export format is not a contracted deliverable), the parsing breaks.
The most insidious variant is the PDF statement. Some institutions, particularly smaller banks, correspondent banks in emerging markets, and specialized custodians, provide statements only as PDF documents. The data is visually structured in tables, but extracting it programmatically requires either OCR (for scanned documents) or PDF table extraction (for digitally generated documents), both of which introduce accuracy risks that compound across thousands of transactions.
The reconciliation workflow that consumes the morning
A typical multi-bank reconciliation workflow starts with format normalization and ends with exception investigation. The steps between are where the operational cost accumulates.
Ingest and parse. Each banking partner’s file arrives via SFTP, email, API pull, or portal download. MT messages need tag-level parsing. CAMT files need XML navigation. CSVs need delimiter detection and header mapping. PDFs need extraction. Each format requires its own ingestion logic.
Normalize to a common ledger structure. All parsed transactions need to map to a single internal format: posting date, value date, amount, currency, debit/credit indicator, counterparty, reference, category, and source identifier. The mapping from each source format to this common structure is where the institutional variation bites. The same logical field lives in different locations, uses different representations, and carries different levels of detail across sources.
Currency and amount normalization. Some sources report amounts with implicit decimal positions (an integer 1500000 meaning 15,000.00). Others use explicit decimals. Some embed the currency code in the amount field. Others store it separately. Some report in the account currency. Others report in the transaction currency with a separate exchange rate field. Normalizing all of these to a consistent amount + currency representation is a transformation step that varies by source.
Temporal alignment. Value dates and booking dates may differ. Some sources report both. Others report only one. Timezone handling matters for institutions operating across geographies. A transaction booked at 11 PM Eastern on March 6 and 4 AM GMT on March 7 should reconcile as the same event, not two separate transactions.
Match and reconcile. With normalized data, the actual reconciliation begins: matching internal ledger entries against external statement entries, identifying breaks, and investigating exceptions. This is the analytically valuable work. Everything before it is mechanical data preparation.
datathere handles the mechanical preparation. Each banking partner’s statement format (MT940, CAMT.053, proprietary CSV, or PDF) is a source. The internal ledger structure is the destination schema. AI-generated mappings handle the field-level translation, including the structural differences between flat and nested formats. Transformation expressions handle amount normalization, date parsing, and debit/credit indicator standardization.
CAMT hierarchy flattening
The specific challenge of CAMT messages deserves detail because it is where most generic integration tools fail.
A CAMT.053 is not a flat list of transactions. It is a hierarchical document where meaning is encoded in the structure. An Ntry (Entry) might represent a batch of individual transactions. The entry-level amount is the batch total. The individual transactions live inside NtryDtls/TxDtls elements with their own amounts, references, and counterparty details.
Flattening this hierarchy into a list of individual transactions requires understanding whether the entry is a single transaction or a batch. If it is a batch, the individual TxDtls records are the transactions. If it is a single transaction, the entry itself is the transaction, and any TxDtls provides supplementary detail rather than child records.
The distinction is encoded in the BtchBookg (Batch Booking) indicator at the entry level. When BtchBookg is true, the entry is a summary and the details are the individual items. When it is false or absent, the entry is a single transaction. Some banks always include this indicator. Others omit it and expect the consumer to infer the structure from the presence or absence of multiple TxDtls elements.
datathere’s AI mapping handles this structural interpretation. When processing a CAMT.053 source, the mapping engine identifies the hierarchy, determines the correct flattening strategy based on the structure and sample data, and produces individual transaction records from batch entries while preserving single-entry transactions as-is. The confidence scores flag entries where the batch/single distinction is ambiguous, directing a reviewer to verify the interpretation before the mapping goes to production.
Multi-source joins for position reconciliation
Transaction reconciliation is one dimension. Position reconciliation — verifying that the balances reported by banking partners match internal records — adds a multi-source join requirement.
An institution’s internal general ledger shows a cash balance for each bank account. Each banking partner reports their view of that same balance in their statement. Reconciling the two requires joining internal ledger records with external statement records on account identifier, matching opening and closing balances, and explaining the differences.
The account identifiers do not always match. The internal ledger uses an internal account code. The bank reports the account using their own identifier — an IBAN, a BBAN, or a proprietary account number. The crosswalk between internal codes and external identifiers is maintained somewhere, often in a spreadsheet that the treasury team manages manually.
datathere’s multi-source join handles this by joining internal ledger exports with external statement data using the account identifier crosswalk as a reference source. The three-way join (ledger, statement, and crosswalk) produces a reconciled position view that shows the internal balance, the external balance, and the difference for each account, without manual spreadsheet assembly.
What changes when the format problem is solved
Treasury operations teams that automate statement normalization report a consistent pattern: the time spent on daily reconciliation shifts from 70% data preparation and 30% exception investigation to 10% data preparation and 90% exception investigation.
The exceptions are the valuable work. A reconciliation break might indicate a missed transaction, a duplicate posting, a timing difference, or a genuine error. Investigating these requires financial expertise, counterparty knowledge, and judgment. Parsing MT :61: lines and navigating CAMT XML hierarchies requires none of these. It is mechanical work performed by expensive people.
The format problem is not going away. The SWIFT MT to ISO 20022 migration will take years. Proprietary exports will persist indefinitely. PDF statements will continue arriving from partners who have not modernized. The question for treasury operations is not whether to deal with format diversity, but whether to deal with it manually every morning or to solve it once with a mapping layer that handles the variation automatically, with quality enforcement that catches parsing errors before they become reconciliation breaks.