Financial data cannot be "probably correct."

Trading and investment platforms

Moving between portfolio management systems, order management platforms, or risk engines introduces severe data risk. When positions don't balance or cash flows diverge, trading desks and compliance officers face immediate operational exposure.

Core scenarios we reconcile:

• Platform cutovers: Comprehensive verification between legacy systems and replacement platforms.
• Open positions & lots: Multi-asset position reconciliation, tax-lot continuity, and cost-basis integrity.
• Transaction history: Trades, executions, corporate actions, and dividend adjustments.
• Valuations & NAV calculations: Catching subtle rounding differences and pricing feed timing gaps.
• Downstream reporting feeds: Confirming risk systems and client valuation statements receive pristine inputs.

Market and reference data

External feeds evolve constantly. Upstream schema adjustments, missing identifier tags, and ticker changes trigger silent mapping failures in downstream engines.

Core scenarios we reconcile:

• Vendor feed integrations: Validating daily market feeds against internal golden-copy repositories.
• Security master updates: Cross-referencing ISIN, CUSIP, SEDOL, and FIGI symbology across disparate vendors.
• Corporate action adjustments: Reconciling stock splits, mergers, and spin-off adjustments across systems.
• Timing cut-offs: Resolving asynchronous publication differences and timezone boundaries.

Ledgers and transactional systems

A double-entry ledger cannot tolerate rounding ambiguities or missing entries. When balancing payment rails, clearing feeds, or subledgers against general ledgers, every cent must be deterministically accounted for.

Core scenarios we reconcile:

• Payment rail reconciliation: Validating transactions across internal journals, gateways, and clearing rails.
• Subledger to General Ledger: Detecting unbalanced batches, timing delays, and unposted journal records.
• Multi-currency balances: Normalizing FX rates, conversion timestamps, and currency cut-offs.
• Duplicate & reversal handling: Distinguishing intentional reversal entries from accidental double-processing.

Data platforms & cloud migrations

Migrating from on-premise operational databases to cloud data warehouses requires mathematical proof that pipeline transformations preserved row counts and business semantics.

Core scenarios we reconcile:

• Source-to-warehouse migrations: Verifying ETL/ELT pipelines from transactional engines into analytical stores.
• Database engine upgrades: Proving zero data corruption during version or engine cutovers.
• Transformation regression testing: Confirming modified dbt, SQL, or pipeline code doesn't distort historical figures.

How complex matching actually works

Simple primary key joins fail in financial systems. Real-world financial reconciliation requires specialized matching engineering:

• Composite identifiers: Joining records when no single unified ID exists across legacy and modern APIs.
• Mapping & normalization tables: Translating disparate internal codes, transaction types, and account structures.
• Effective dates vs transaction dates: Distinguishing booking times, trade dates, and settlement cut-offs.
• Tolerance rules: Applying explicit epsilon boundaries for floating-point calculations vs strict integer penny matching.
• Exception classification: Separating genuine missing rows from timing lags, transformed codes, and value shifts.