Even when two systems report accurate records, they can occupy different stages of the same event; the expected time window, source calendar, time zone and state transition together establish whether that timing relationship is valid.

A reconciliation horizon is the latest point for which the control can assert that the required records have arrived and the defined tests have run.

The horizon records:

• the covered business or settlement period;
• the data watermark reached by each source;
• the expected delivery schedule;
• accepted lateness and calendar rules;
• outstanding pending states;
• files, messages or sequences still expected;
• the time at which lateness becomes an exception.

A recent timestamp establishes freshness. Completeness requires sequence checks, control totals or source confirmations that prove the expected population has arrived; only then can the timestamp contribute to the horizon.

Until the later record arrives, an expected resolution date keeps each known timing difference visible. Unexplained lateness becomes a break. Continuous reconciliation may issue a bounded interim assertion, while the period closes only after separate evidence confirms the required population and outcomes.

At ingestion, the control layer stores the source payload or a verifiable reference together with the source system, delivery channel, record version and receipt time. For file-based sources, it also records filenames, sequence numbers, checksums, expected schedules and trailer totals; for event streams, it records offsets or equivalent source positions.

Before financial matching begins, validation identifies malformed records, duplicate deliveries, broken sequences and incompatible control totals. A missing or rejected input creates a completeness exception that stays visible within the control scope.

Normalization converts source-specific fields into comparable financial facts while keeping the original representation available. Currency codes, signs, dates, account identifiers, references and state labels follow versioned transformation rules, and lineage links every normalized value to its source field and transformation.

Before testing agreement, the control establishes which records should exist. Message sequences, source manifests, transaction counts, batch totals, opening positions or delivery schedules may establish the expected population.

As records arrive, matching can run continuously. The reconciliation horizon records the latest complete point reached by every required source and marks the boundary of each formal control assertion.

At the transaction level, matching establishes identity; at the batch level, control establishes membership and aggregation; at the position level, the opening balance, movements, adjustments and closing balance establish financial continuity across the covered period.

Depending on its cause, resolving a break may call for a missing source record, corrected reference, external investigation, ledger posting, fee allocation, reversal or approved accounting adjustment. The resolution path records that action in the system holding authority for the affected fact.

Where financial or policy impact calls for independent approval, manual actions carry maker-checker control. Rule changes, tolerance changes and bulk closures follow their own effective-dating and approval process.

If a late arrival or corrected source record changes the available evidence, the control triggers a targeted replay of affected reconciliation edges and records the previous result, the event that caused reassessment and the new outcome. Dependent batches, positions and closed periods receive an explicit impact assessment.

Closure follows only after the authorised action and rerun resolve the failed assertion. The closed case links the source data, original break, root cause, financial effect, corrective action, prior and new control results, reviewer, supporting records and final closure decision.

A canonical model makes fields comparable across sources. It does not replace the source message or confer authority on a transformed value.

For every normalized record, the architecture retains:

• the original source payload or a verifiable reference;
• message type, business service and schema version;
• sender, receiver and transport path;
• source field names and namespaces;
• original and normalized values;
• the transformation and code-list versions;
• translation or truncation indicators;
• validation results and processing time.

When an ISO 20022 message embeds or derives a legacy representation, the reconciliation record preserves both forms and the translation lineage between them. A field absent from the legacy form remains distinguishable from a field supplied by the originating party.

Each transition records the evidence available at that time. A provisional match reduces investigation work but does not assert final settlement or population completeness.

TIPS settles instant payments in central bank money on a 24/7/365 basis. Financial positions and formal reports still use defined accounting and operational boundaries. The TARGET Services Annual Report, for example, reports TIPS activity continuously while applying a defined end-of-business-day snapshot for T2-related liquidity reporting. European Central Bank: What is TIPS? TARGET Services Annual Report 2025

The architecture records these clocks separately. It does not infer completeness from the uninterrupted availability of the rail.

Event-driven controls can:

• validate each incoming message;
• connect status changes to the payment object;
• detect duplicates and incompatible transitions;
• create or clear breaks as evidence arrives;
• update exposure and ageing in near real time.

Periodic controls can:

• confirm file and sequence completeness;
• reconcile batches, settlement groups and positions;
• establish source watermarks;
• test opening-to-closing balance continuity;
• approve a defined business or accounting period.

The two modes share the same record graph, rules and exception cases. Periodic control does not repeat the transaction history; it establishes that the event population is complete for the stated horizon.

Each event retains event or effective time, source processing time, ingestion time, sequence position, version and correction status. The engine orders financial meaning by approved source rules rather than arrival time alone.

A late or corrected record triggers a targeted replay of affected transaction, batch and position controls. Replay preserves the former match, identifies the initiating event, applies the effective rule version and records the resulting state. A correction that affects an approved horizon generates an impact assessment and can reopen the relevant exception or attestation.

From November 2026, financial institutions must be able to receive camt.110 investigation requests through Case Management; in-flow translation can carry an embedded MT 199 for legacy handling. From November 2027, eligible institutions are scheduled to exchange camt.110 and camt.111 through Case Management without in-flow translation for exceptions and investigations. Swift ISO 20022 Exceptions and Investigations FAQ

During the transition, the internal case preserves:

• payment identity and UETR;
• external investigation reference;
• original and translated messages;
• sender, receiver and routed participant;
• request, response and escalation states;
• the relationship between external case status and internal break status;
• evidence supporting resolution and closure.

Continuous reconciliation therefore combines low-latency event processing with explicit completeness boundaries. ISO 20022 improves the available structure, while source authority, semantic lineage, watermarks, replay and governed closure determine the strength of the reconciliation assertion.

When a platform commits delivery and payment as one indivisible transaction, it can remove the interval in which one leg completes and another remains pending. Reconciliation still tests:

• whether the correct assets and parties entered the transaction;
• whether every precondition came from an authorised source;
• whether the platform committed the intended state transition once;
• whether issuance, redemption and supply remain supported;
• whether off-platform cash, reserves and accounting records agree;
• whether a failed or reversed transaction produced the required residual state;
• whether participants can retrieve independent evidence of the result.

Atomic execution strengthens one edge of the record graph. It does not establish authority for facts outside the platform.

Project Agorá explores tokenised commercial bank deposits and tokenised central bank reserves on a multi-currency programmable platform. Its design connects several layers rather than collapsing every financial record into one database.

The reconciliation interfaces include:

• commercial-bank deposit liabilities to tokenised-deposit representations;
• participant instructions to programmed transaction conditions;
• tokenised deposits to the settlement obligation between banks;
• tokenised central bank reserves to central-bank account authority;
• platform outcomes to core banking, treasury and accounting records;
• issuance and redemption to the supported assets and liabilities.

In July 2026, 28 financial institutions and central banks completed real-value testing across selected currencies. The programme covered 17 transaction scenarios totalling approximately CHF 800,000. These results demonstrate controlled testing of the architecture; they do not establish general production operation or universal legal treatment. BIS Project Agorá

Swift’s shared ledger introduces a common orchestration layer while banks retain control of assets and funding. In the described initial design, settlement remains connected to existing infrastructures.

The reconciliation architecture therefore tests four edges:

1. the participating bank’s instruction and funding state against the shared orchestration record;
2. the shared commitment against the relevant tokenised-deposit record;
3. the orchestration outcome against completion in the external settlement infrastructure; and
4. the final result against each bank’s core and accounting postings.

On 9 July 2026, Swift said the ledger was ready for initial use and that 17 banks were preparing to pilot live transactions using tokenised deposits. The distinction between readiness, pilot activity and established production service remains explicit. Swift

For a tokenised deposit or other issued representation, the control tests the supply roll-forward:

Opening token supply + authorised issuance − completed redemption ± governed corrections = closing token supply

Issuance requires evidence of:

• the issuing institution and legal instrument;
• the customer or participant obligation represented;
• the supporting deposit or liability record;
• authorised amount, currency and beneficiary;
• unique token or position identity;
• completion on the platform and posting in the issuer’s core records.

Redemption requires corresponding proof that the token state, external payment or account credit, issuer liability and supply reduction agree. A token marked redeemed without the required external cash or core-banking result creates a boundary break.

Platform commitment and settlement finality can coincide in an integrated design. Where settlement remains off-platform, they remain separate states. The applicable settlement mechanism determines irrevocability and unconditional completion; reconciliation records the evidence connecting that result to the shared-ledger event. See Settlement Finality.

A smart contract or programmed workflow can act only on the facts supplied to it. For every external condition, the architecture defines:

• the data provider and authority;
• the event, timestamp and validity period;
• the method of delivery and authentication;
• treatment of missing, conflicting or corrected data;
• the contract version and execution result;
• override, suspension and dispute authority.

Atomic execution based on incorrect condition data produces a consistent platform state and an incorrect economic outcome. Reconciliation must therefore test the authority and lineage of the inputs as well as the resulting transaction.

For every shared-ledger design, the authority map identifies:

• facts made authoritative on the shared platform;
• facts still established by an issuer, bank, RTGS or core system;
• the interfaces that connect those authority domains;
• the state and timing relationship expected at each interface;
• the party able to correct each fact;
• evidence available during normal operation and failure.

Shared infrastructure can reduce reconciliation within a common execution boundary. It increases the importance of issuance, redemption, settlement, core-banking and evidence-access controls at the edge of that boundary.

The evidence pack links to retained source data according to approved retention and access rules. It does not require duplicating every payload inside the case-management interface.

Within the defined control scope, status applies to the covered account, rail or source. One account, rail or source can be approved while another remains provisional or failed.

The metric model covers six layers:

• Coverage: whether expected records and value arrived.
• Agreement: how records reached an approved match.
• Exposure: the financial and control consequence of open breaks.
• Resolution: ownership, ageing, escalation and closure.
• Quality: recurrence, corrections, rule performance and manual intervention.
• Assurance: evidence completeness, review and reopened conclusions.

A published match rate identifies:

• whether the denominator uses records, economic events or financial value;
• the control scope and reconciliation horizon;
• excluded pending states and approved timing items;
• whether both sides of a matched pair are counted;
• treatment of batches, splits and many-to-many groups;
• treatment of tolerated, AI-assisted and manual outcomes;
• the rule and source versions used.

Combining these outcomes into one headline rate can be useful for throughput reporting. It does not replace the separate control-quality measures.

Metrics are segmented by:

• account, legal entity and product;
• currency, rail and settlement mechanism;
• source system and external participant;
• transaction and settlement grain;
• matching rule and tolerance;
• break class, severity and root cause;
• value band and customer-funds relevance;
• business day, horizon and operating calendar.

Segmentation reveals concentrated failures that an aggregate rate can conceal.

Severity and escalation use these dimensions together. A low-value break can still be critical when it exposes a completeness failure or customer-funds allocation gap.

The reconciliation team can coordinate an external dependency. It cannot transfer internal accountability to the bank, processor, middleware provider or vendor causing the delay.

When resolution changes a financial record:

1. the case identifies the authoritative record requiring action;
2. an authorised role creates the posting, reversal, correction or adjustment;
3. a separate approval applies where policy requires maker-checker control;
4. reconciliation reruns the original assertion against the resulting evidence; and
5. the control reviewer approves closure or records the remaining exposure.

The action that changes value is not the same as the decision that the reconciliation break is resolved.

An attestation records:

• the control and period covered;
• sources and horizons achieved;
• assertions tested;
• complete and incomplete populations;
• open breaks by class, age and exposure;
• approved timing items and residual treatment;
• control failures or data limitations;
• material changes since the prior run;
• reviewer and approval time.

The evidence chain is:

records → control run → breaks → resolution → evidence → attestation

This chain allows architects, operations, finance, risk and assurance teams to evaluate the same result without assigning one metric more authority than the records and policies supporting it.