An audit of a corporate cross-border payment program is not primarily an exam on whether payments arrived. Auditors assume payments generally arrive. What they examine is whether the payment program produced a complete, accurate, and tamper-evident record of what happened: who authorized each payment, which entity executed it, through which financial institutions it passed, at what FX rate it converted, when settlement finality occurred, and what the resulting ledger entry was. If that chain is reconstructible from your records, you pass. If reconstruction requires calling correspondent banks or manually piecing together emails and MT103 PDFs, you have an audit-readiness problem regardless of whether all the payments actually settled correctly.
What Auditors Actually Ask For
Internal auditors reviewing cross-border payment programs typically work from a set of population-sampling questions. For a randomly selected payment from the review period, they will ask for:
- The original payment instruction with the authorization trail (who approved it, in what system, at what timestamp).
- The outbound SWIFT message or equivalent payment file, showing all structured fields including the UETR if gpi was used.
- The FX rate confirmation, typically a deal ticket or rate confirmation from the bank, showing the rate applied and the time the rate was locked.
- The settlement confirmation, typically a bank debit confirmation (MT900 equivalent) and, where available, a beneficiary credit confirmation (MT910 equivalent or gpi tracker record).
- The ledger entry that corresponds to the settled payment, showing the accounting treatment and the reconciliation match.
- The bank statement or account statement extract showing the actual debit, with value date, confirming alignment with the ledger entry.
External auditors performing financial statement audit procedures will request the same chain for material transactions and will select samples from accounts payable, intercompany transfers, and FX settlements independently. If any link in the chain requires manual reconstruction, that is a finding.
The Common Gaps in Cross-Border Payment Records
Three gaps appear consistently in cross-border payment documentation when treasury teams have not built an explicit audit trail capability into their infrastructure.
First, the FX rate is not linked to the payment. The treasury team knows what rate was used because the bank's FX confirmation email arrived on the same day, but the payment record and the rate confirmation are stored in separate systems with no machine-readable link. Reconstructing which rate applied to which payment requires a manual date-matching exercise.
Second, the settlement confirmation is missing or delayed. For correspondent bank payments, the MT910 credit confirmation may arrive days later, or not at all if the correspondent does not send confirmations proactively. For gpi payments, the tracker record is technically available but the treasury team does not have a system that captures it at the time of settlement and attaches it to the payment record.
Third, the reconciliation trail is implicit rather than explicit. The reconciliation happened, but it happened in a spreadsheet that shows which invoices were matched to which payments. That spreadsheet is not a system record. It is a manual artifact that cannot be easily verified as complete or unmodified after the fact.
What an Audit-Ready Record Contains
An audit-ready payment record is structured such that for any transaction, a reviewer can follow a single data thread from authorization to ledger close without leaving the system. That means the record must contain:
- Authorization metadata: approver identity, timestamp, approval reference, and the approval policy that applied (single approver, dual control, amount-based escalation).
- Payment instruction data: all ISO 20022 or legacy SWIFT fields submitted, including the end-to-end ID that links the instruction to the confirmation.
- FX rate data: the rate, the rate timestamp, the deal reference, and the notional amounts in both currencies, linked to the payment by shared reference.
- Settlement confirmation data: settlement system used, settlement timestamp (not instruction timestamp), confirmed settled amount, and any intermediary charges deducted.
- Reconciliation event: the match between the payment instruction and the account statement debit, with the reconciliation timestamp and the system that performed the match.
- Ledger entry reference: the journal entry or accounts payable posting that cleared the original obligation, linked by reference to the payment ID.
When these fields exist as structured data in a system of record rather than as PDFs in an email folder, the audit sample exercise takes minutes per transaction rather than hours.
Immutability and the Tamper-Evident Requirement
An audit trail that can be edited after the fact is not an audit trail. This is not a hypothetical concern. Auditors are trained to look for gaps in timestamp sequences, amended records without change logs, and reconciliation entries that post-date the underlying transaction by implausible margins.
From an infrastructure standpoint, tamper-evidence requires that once a payment record is created, its core fields are write-protected and that any change (a correction, an amendment, a status update) is logged as a new event rather than an overwrite. The original record must remain readable. This is standard practice in event-sourced systems but requires explicit design in any payment infrastructure built on top of a mutable database.
We are not arguing that most treasury teams are falsifying records. We are saying that without immutability by design, an auditor has no way to verify that the records have not been modified, and will note that gap in their findings regardless of whether any modification occurred.
Building This from the Start vs. Retrofitting
Audit-readiness is significantly cheaper to build in from the beginning of a payment program than to retrofit after the fact. The core infrastructure decisions, how payment events are stored, whether FX rates are linked by reference or by proximity, whether reconciliation is a system event or a spreadsheet exercise, are architectural choices that affect every transaction the program will ever process.
For a treasury team starting a new cross-border payment program or evaluating infrastructure for an existing one, the audit readiness question is worth asking before choosing tools, not after the first external audit finding. Birch Hill's settlement infrastructure records each leg of each payment as a structured, immutable event: instruction, rate lock, settlement confirmation, reconciliation match, and ledger entry reference. This is not a compliance feature added on top. It is how the settlement flow is designed, because without a complete chain, reconciliation breaks cannot be reliably detected before close.