Compare the books.
Match execution extracts by trading date, venue, member and record ID. Compare instrument, account, side, quantity, price, currency, net amount and settlement date.
LOCAL WORKBENCHEXCHANGES · BANKS · FINANCIAL MARKETS
Financial records.
Reconciled.
Verifiable.
Reconcile trades, cash and positions across exchanges, banks, brokers, DTVMs and asset managers. Process locally, adapt to your jurisdiction and connect approved evidence to the Bloch Protocol.
Local comparison is available below. Exchange connectors, institutional deployment and on-chain publication require integration and qualification.
THE EVIDENCE PATHARCHITECTURE
01 / INSIDE YOUR ENVIRONMENT
Trading venueClearing recordsInternal ledger
≋
LOCAL / OFF-CHAINReconcile + retain evidenceSource files · rules · breaks · approvals
Private records stay localInstitution controls access
↓
Controlled releaseReviewed commitment + external signer
INTEGRATION GATE02 / BLOCH PROTOCOLOn-chain evidence referenceExact transaction · block · qualified finality
A chain reference must be bound to the exact approved evidence.
LOCAL FIRSTCSV comparison in your browser
EXACT DECIMALSNo floating-point amount matching
REPRODUCIBLESource digests + versioned rules
BLOCH PROTOCOLGoverned on-chain integration path
01 / EXCHANGE OPERATIONS
From the trading day
to the audit file.
A common workflow for post-trade operations, bank ledgers, portfolio oversight, internal control and independent review.
Make every break visible.
Separate field differences, missing records and duplicate keys. Keep both source values and row references and add a dated review journal bound to the exact report. Download the history without changing comparison outcomes.
LOCAL WORKBENCHExtend across operations.
Design partner-specific adapters for positions, cash, settlement confirmations and corporate actions, with their own identifiers, cutoff rules and approval controls.
PARTNER INTEGRATION01ExtractRetain original source files
02ReconcileApply an explicit rule version
03ReviewExplain and approve exceptions
04ProveRetain evidence; qualify publication
MODULAR / ONE EVIDENCE CORE
Built around your desk.
Configured for your market.
Four working local comparison modules, with shared exception handling, evidence exports and configurable source schemas. Institution profiles select a starting module; you can change it.
Trading venues
Compare trade extracts, clearing records and member books. Review executions, missing records and duplicates.
Trades & executions ↓Banks & payments
Reconcile internal cash entries against statement extracts, including debit/credit direction, value date, amount and posting status.
Cash & ledger entries ↓Brokers & DTVMs
Compare execution and allocation extracts. Extend to cash and custody snapshots through the same module selector.
Trades + cash + positions ↓Asset managers & funds
Compare portfolio snapshots with administrator or custodian files, including quantities, prices and reported market values.
Positions & custody ↓Custodians & administrators
Match instrument positions and cash records at an agreed cutoff. Preserve source values for independent review.
Positions + cash ↓Other market participants
Reuse the module registry, map source headers and export a versioned configuration for your own integration.
Configure your module ↓GLOBAL + LATAM / BRAZIL FIRST
A common core.
Local data contracts.
Country presets configure file conventions and identify regulatory review areas. They do not activate connections or determine legal compliance.
Compose the operating model.
Choose institution, module, date and decimal conventions, delimiter and column mapping. Record jurisdiction, purpose, processing region and retention-policy references in a portable JSON configuration.
- Versioned module and evidence schemas
- Explicit GDPR scope declaration
- Extensible adapters and policy references
Local formats. Explicit boundaries.
Brazil presets support DD/MM/YYYY, decimal commas and semicolon CSVs. Use private local references for Pix, STR, B3, bank statements and portfolio systems after mapping your authorized extracts.
- LGPD + ANPD · BCB/CMN · CVM review
- Mexico, Colombia, Chile and Argentina profiles
- Custom profile for other LatAm jurisdictions
No live B3, Pix, STR, Open Finance, SPEI or supervisory reporting connection is enabled. Calendars, market cutoffs, chart-of-accounts mappings and regulatory filings are institution-specific adapters.
LOCAL / MODULAR RECONCILIATION WORKBENCH
Your files.
Your environment.
Compare trade, cash, position or Bloch receipt extracts without uploading them. Processing and report generation happen in this browser; files remain in memory until you clear or close the page.
Download the offline workbench ↓Map unlike source extracts ↓
Configure your module
GLOBAL + LATAMCustom source mapping + policy references
Map a canonical field to its source column, for example {"account":"conta"}. Unmapped names remain canonical. Both files use the same mapping and format. Normalize differing systems before comparison.
These references are stored in the private evidence manifest. They do not enforce retention, authenticate permissions, verify residency or certify compliance. Institutional controls must implement those policies.
Applying a configuration, loading files or rerunning clears the current report and review journal. Download them first. Examples reload using the selected module.
TRADE COMPARISON / V1
SYNTHETIC EXAMPLEMatching rules, CSV schema and limits
Required columns (order may vary):
record_id,trade_date,settlement_date,venue,member,account,instrument,side,quantity,price,currency,net_amountThe key is trade_date + venue + member + record_id. All remaining fields must match. Outer whitespace is trimmed; enum fields and currency are uppercased. Identifiers remain case-sensitive. Decimal amounts are compared exactly, with up to 8 fractional digits and zero tolerance. Dates use the selected format and normalize to YYYY-MM-DD. Duplicate keys always require review.
Two-file comparison within the selected module. Source authenticity and completeness are not verified. Use consistent cutoffs and exports. Output includes private source values; retain it in your approved environment.
Unique keys—
Matched—
Require review—
Source rows A / B—
Reconciliation outcomes
KEY COUNTSEach composite key appears once. A duplicate in either file takes priority over other outcomes.
Evidence manifest
LOCAL / NOT ON-CHAIN- Rule version
- trade-comparison.v1
- Source integrity
- SHA-256 of input file bytes
- Report digest
- —
The digest identifies the exact downloaded report bytes. It does not authenticate source records or prove a chain timestamp. Keep this manifest and its private data off-chain.
Investigation overview
Where fields disagree
Keys with differing values, by field. One key can appear in several bars. Missing records and duplicates are separate outcomes.
Review progress
Latest annotation per exception. Explained records retain their original discrepancy. Reviewer labels are self-declared.
Full-report counts. Selecting a bar replaces the queue filters with that selection. Bars show record counts, not financial exposure or risk scores.
Exception review journal
LOCAL ANNOTATIONS / UNSIGNEDSelect Review exception in the records table to document a discrepancy. Entries retain the original outcome and bind to this exact report. Names and timestamps are self-declared; an explanation is not an approval or a corrected match.
0Not reviewed
0Active follow-up
0Explained
0History entries
Keep evidence, original CSVs and review JSON together in approved local storage. To resume a previous report, use Verify below, then open it for review. Up to 1,000 journal entries.
History for this exception
Keep the full case together
PORTABLE / LOCAL ONLYPackage the complete evidence, original CSVs, review journal, applied configuration and a fresh verification receipt in one .bloch.json file. Filters do not remove records from this case.
Contains private source data and review notes. The file is unencrypted and unsigned; retain it in your institution's approved storage.
Exact case SHA-256
Retain the digest separately before a future verification. New files or review entries invalidate this prepared snapshot.
Investigation queue
LOCAL SEARCH + FILTERSSearch ignores letter case and accents; every space-separated term must occur in a key, normalized source value or latest review label/note. Filters combine. Search never changes matching rules. Follow-up first orders: follow-up required, reopened, not reviewed, investigating, explained, then matched. Latest journal entry uses sequence, not a trusted timestamp.
All selected keys across every page. Includes private review notes and both evidence/journal digests; retain the full JSON files separately.
| Record / key | Outcome | Source rows A / B | Comparison detail |
|---|
LOCAL SOURCE PREPARATION / TRACEABLE TRANSFORMATIONS
Different extracts.
One explicit contract.
Map columns from each institution's CSV independently. Choose date and decimal conventions, inspect excluded columns, and validate every mapped record before reconciliation. Nothing is uploaded.
The module and policy references are captured separately from the workbench. Change the applied configuration above, then use its settings here. Exact or configured header names are preselected; every other mapping requires your selection.
Preparation rules and retained evidence
Up to 64 input columns and 5,000 rows per source. Comma or semicolon delimiters, ISO or DD/MM/YYYY dates, decimal dot or comma. No thousands separators, guessed values, enum translation, currency conversion, netting or duplicate removal. All module fields are required. Mappings are one-to-one; excluding columns requires acknowledgement on each source.
Output uses the existing module rules: trim outer whitespace, normalize dates and exact decimals, uppercase enums/currencies and lowercase Bloch hashes. Row order and duplicate multiplicity are preserved. The charts count cells whose text changed; a normalized value is not an approved correction.
Keep the original extracts, prepared CSVs and preparation receipt together. Subsequent evidence and case files bind to the prepared CSVs only. The separate receipt links input/output hashes, mappings, exclusions and every row reference; it contains filenames and metadata but no source cell values. It is unsigned and does not authenticate an institution or establish source completeness.
Prepared CSVs are machine inputs. Formula-like identifiers are preserved to keep matching exact; import columns as text if opening these files in spreadsheet software.
Prepared sources and row lineage
LOCAL / ZERO INFERRED VALUESPreparation receipt SHA-256
Download and retain the receipt before opening these files for reconciliation. Preparation receipts and original extracts are not embedded in the six-component case format.
Loading replaces the current reconciliation files, report, configuration and review session. Download unsaved work first. It does not run reconciliation or change this preparation snapshot.
RETAINED PREPARATION / INDEPENDENT RECOMPUTATION
Trace each transformation.
Reproduce every byte.
Reopen a preparation receipt with both original extracts and both prepared CSVs. Reproduce the mappings and normalization locally, verify every row reference, and optionally link the result to a reconciliation report.
What this verification establishes
Both original file digests must match the preparation receipt. The app then reruns its declared mappings, exclusions and module rules, checks every normalization count and row reference, and requires the supplied prepared CSVs to match the reproduced bytes exactly. Renaming retained files is allowed; changing line endings, ordering or values is not.
If evidence is supplied, its sources must bind to the prepared CSVs, its full configuration and data mode must agree with preparation, and every reconciliation outcome is recomputed. No review journal is imported or verified here. Use the evidence or case verifier for retained review history.
Without independently retained digests, a coherent replacement of the files and declarations can pass consistency checks. Timestamps, filenames, data mode, policy references and mapping authorization are declarations. This does not authenticate sources, prove completeness, prevent rollback, certify compliance or verify on-chain inclusion.
Verified preparation path
EXACT BYTES / LOCAL CONSISTENCYSelect a node to inspect its file binding or recomputed transformation. The final edge is verified only when a reconciliation report is supplied.
Retained preparation SHA-256
Verification receipt SHA-256
The verification receipt records consistency checks and file digests. Keep all originals, prepared files, preparation receipt and any evidence together. Neither receipt is a signature or part of the six-component case format.
Loading replaces the workbench configuration, files, report and review session. Download unsaved work first. Only the verified prepared files are loaded; reconciliation must be run again. Supplied evidence and review history are not resumed.
INDEPENDENT RECOMPUTATION / LOCAL FILES
Reopen the evidence.
Check every outcome.
Start with the exported evidence JSON and both original CSVs. Recompute file digests, matching rules, records and outcomes locally. An optional retained SHA-256 checks the report against a separately stored reference.
Retain the digest separately before verification. A consistent replacement of all files cannot be detected without a trusted external reference. Review journals are unsigned and have no protected history or rollback detection. Preserve original JSON formatting.
Local consistency checks passed
RECOMPUTED / NOT CERTIFIEDExact report SHA-256
Opening this report replaces the current comparison and review session above. Download any unsaved work first. This check does not authenticate the source, reviewer, timestamp or on-chain status.
ONE CASE FILE / SIX VERIFIED COMPONENTS
Retain once.
Reopen with evidence.
Import a case prepared in the workbench. The app checks each component and recomputes the comparison from the embedded original CSVs. Resume the exact report and review history, or download individual verified components.
Without a separately retained digest, a coherent replacement of the case can pass internal checks. The file contains private data in plaintext. Verification does not authenticate people, prove source completeness, prevent rollback or verify an on-chain claim.
Compare two verified case snapshots ↓Retain originals, preparation and case in one audit bundle ↓
Case consistency checks passed
SIX COMPONENTS / RECOMPUTEDExact case SHA-256
| Component | UTF-8 bytes | SHA-256 | Local export |
|---|
Opening replaces the current comparison and review session. Download current work first. Original evidence bytes are preserved; running reconciliation again creates a new report. The imported case is a snapshot and does not change when you add new review entries.
ONE RETAINED FILE / COMPLETE LOCAL LINEAGE
Keep the originals.
Reopen the whole trail.
Package original extracts, their preparation receipt and an existing reconciliation case together. Reproduce preparation, verify every case component, and retain the exact evidence and review history in one local file.
Prepare an audit bundle
FIVE COMPONENTS / EXISTING CASE PRESERVEDStart with a case exported from the workbench after reconciling prepared CSVs. Supply the preparation receipt and its original extracts. Both prepared CSVs are already inside the case; every link must verify before the bundle can be generated.
The bundle contains private originals, including excluded columns, prepared records and review notes in plaintext. Keep it in your authorized environment. It is not encrypted or signed. The total serialized bundle must fit within 96 MiB, even when individual inputs fit their limits.
Audit bundle ready
Bundle SHA-256
Verify and reopen a retained bundle
ORIGINALS → PREPARATION → CASE → REVIEWBundle verification and retention boundaries
The five fixed components are the unchanged six-component case, unchanged preparation receipt, two original extracts and a recomputed preparation verification receipt. Component bytes and hashes are checked; the embedded case, preparation, configuration, outcomes and review binding are independently verified. No component is executed or automatically extracted.
Input digests optionally gate bundle creation. Digests embedded in a bundle are internal bindings, not independently retained references. On reopening, use a separately stored SHA-256 of the whole bundle to detect replacement against that reference. Without it, a coherent replacement can pass consistency checks.
The diagram shows checked data relationships, not chronology, authenticated custody or on-chain transactions. Local timestamps, reviewers and mapping authorization remain declarations. The bundle does not establish source completeness, authorized approval, rollback protection, regulatory certification or on-chain inclusion.
Select a node to inspect the retained originals, reproduced preparation, case or bound review journal.
| Component | UTF-8 bytes | SHA-256 | Local export |
|---|
Retained bundle SHA-256
Verification receipt SHA-256
Opening replaces the current workbench session with the exact retained report, prepared CSVs and review history. Download unsaved work first. New review entries do not change this bundle snapshot; retain an updated case and prepare a new bundle when needed.
VERIFIED SNAPSHOTS / EXPLICIT CHANGES
See what changed.
Keep both references.
Compare a baseline case with a candidate under the same module, configuration and rules. Inspect additions, removals, source changes and review changes. Both cases are verified before comparison; their order is your selection.
Comparison scope and interpretation
Keys match exactly. Changed identifiers or cutoff dates in a key appear as removal plus addition; no continuity or automatic matching is inferred. Keep source A/B roles and dataset scope aligned. Synthetic and local-file cases cannot be mixed.
Normalized source records are compared as multisets: duplicate multiplicity matters, row order does not. Per-field counts can agree while record combinations differ. Row-reference moves are reported separately where source values agree. Review history compares each key's ordered annotations, including declared timestamps, while ignoring global sequence numbering.
Unchanged means normalized records, outcomes and per-key annotations agree; original file bytes can still differ. The app does not establish chronology, source completeness, approved corrections, settlement or on-chain status. It never carries review decisions into another case.
Outcome transitions
FULL COMPARISON / KEY COUNTSRead baseline rows to candidate columns. Absent marks added or removed keys. Select a count to focus the records below; a change to Matched is a comparison result, not an approval or settlement confirmation.
Exports include all keys regardless of filters. JSON retains private records and review notes from both cases; CSV summarizes all key changes. Neither export is an importable case file or a signed audit opinion.
| Record / key | Change | Outcome transition | Retained details |
|---|
Comparison JSON SHA-256
Opening a case replaces the current reconciliation session above. Download unsaved work first. The comparison remains a separate snapshot and does not update when you add review entries.
03 / OFF-CHAIN + ON-CHAIN
Keep the records private.
Make the evidence verifiable.
The local Bloch receipt module compares imported on-chain observations with internal records. The Bloch Protocol is also the proposed shared evidence layer. Your institution retains the detailed books, audit material and control of what may be released.
The complete audit trail
- Source records, account references and business context
- Exact comparison rules and reproducible results
- Reviewer decisions, access and retention policies
- Private opening material for a reviewed commitment
The browser workbench performs local comparison. Authenticated feeds, approvals, encrypted retention and organizational controls belong in the institutional deployment.
A minimal evidence reference
- Publish only an approved, reviewed hiding commitment
- Sign through an institution-controlled signer
- Retain the exact transaction and block reference
- Verify inclusion, canonicality and finality separately
This site does not sign or broadcast transactions. The local report hash is not a qualified hiding commitment. No private records, account IDs or source-file digests belong in the public payload.
AVAILABLE BLOCH NETWORK RESOURCES
Inspect the chain behind the evidence.
Use the public explorer and operator references when designing the receipt verification and network adapter.
04 / AUDITABLE BY DESIGN
Re-run the comparison.
Follow the evidence.
Give an independent reviewer the source extracts, rule version and exact report. Compare the results again before drawing conclusions.
Source → result
Retain both file digests, source row references, normalized values and field-level differences. Duplicate keys never disappear into a match.
Result → review
Keep decisions and reviewer signatures in your controlled case system. A browser-generated report is unsigned and its creation time comes from the local clock.
Review → chain
For a qualified integration, verify the approved commitment opening against the exact chain payload and an independently assessed receipt. A txid alone is insufficient.
GOVERNANCE / PRIVACY + REGULATORY SCOPE
Controls you can inspect.
Obligations you can map.
Start with the institution's actual activities, licenses, countries and data flows. The catalog below links official sources and identifies implementation areas; it is a starting register, not a compliance certificate or exhaustive legal determination.
Implemented in this workbench
- Local processing; no file-upload endpoint, analytics, third-party scripts or remote font requests.
- Network connections blocked by the content security policy. Source records are held in page memory without application persistence.
- Strict module fields, bounded files, explicit duplicate handling and exact values. Reports record the applied configuration.
- No signer, publication endpoint or transaction broadcast. Private records and local report digests are never automatically placed on-chain.
Required in an institutional deployment
- Identity and role-based access; separation of preparation, review and approval; authenticated source adapters.
- Approved processing purpose and lawful basis; field minimization, rights requests, retention, legal holds and controlled deletion.
- Encryption and key custody, residency and transfer review, monitoring, incident response, continuity and recovery.
- Reviewed commitment privacy, institution-held signing, exact payload binding, source independence and chain-evidence verification.
Brazil / LGPD, ANPD, Bacen–CMN and CVM
Privacy: map purpose, data-subject rights, retention, security and international transfers against the LGPD. Review ANPD rules on incident communication and international transfers.
Bacen / CMN: identify the institution's applicable cybersecurity, outsourced-processing and internal-control rules. CMN 4.893 and BCB 85 have distinct scopes; review the consolidated text and amendments, including the rules affecting brokers and DTVMs.
CVM: map intermediary records and controls, portfolio-management procedures, fund-specific obligations and PLD/FTP scope. Reconciliation exports can support a review workflow; the workbench does not submit regulatory reports or perform the institution's AML program.
CVM 35 · intermediaries ↗CVM 21 · portfolio managers ↗CVM 175 · investment funds ↗CVM 50 · PLD/FTP ↗
Also assess bank secrecy, accounting and reporting, record retention, market infrastructure and self-regulatory requirements applicable to the institution. These require additional local mapping.
Global / GDPR, financial-sector resilience and custom jurisdictions
Where GDPR applies, map processing principles, lawful basis, rights, privacy by design, security and international transfers. EU financial entities must separately assess whether DORA's operational-resilience and ICT requirements apply. Other jurisdictions need their own privacy, securities, banking, recordkeeping and reporting register.
LatAm / Mexico, Colombia, Chile and Argentina
Mexico: review the current LFPDPPP, plus the institution's CNBV and Banxico obligations. Colombia: determine the applicable scope of general personal-data rules and financial-data rules; add SIC and financial-supervision requirements. Chile: review current Law 19.628 and CMF obligations, with a transition review for Law 21.719. Argentina: map Law 25.326 and the institution's AAIP, BCRA and CNV requirements.
Mexico · LFPDPPP ↗Colombia · SIC transfer guidance ↗Colombia · scope and exclusions ↗Chile · Law 21.719 transition ↗Argentina · Law 25.326 ↗
Country profiles provide formatting presets and review context. Sector-rule mappings for these countries, and additional LatAm jurisdictions, must be completed by the institution.
Source review: 24 September 2026. Applicability, effective dates and amendments must be rechecked for each deployment. Retention and jurisdiction fields in the configuration are declarations, not technical enforcement. Download the customizable regulatory register JSON ↓ and read the control and integration register ↗.
05 / DEPLOYMENT PATH
Start local.
Qualify each connection.
A practical sequence from comparison to institution-operated evidence infrastructure.
Local workbench
Four modules, exact comparisons, Global/LatAm profiles, searchable queues, interactive charts, exception journals, verified case files, snapshot comparisons and an offline package.
Institutional runtime
Map exchange formats and trading calendars; integrate authenticated sources, identity, reviewer approvals, retention and recovery in the institution's environment.
Bloch evidence adapter
Review commitment privacy, signer custody, payload support, fees, inclusion and finality verification before enabling approved publication.
BLOCH DATA / FINANCIAL RECONCILIATION + AUDIT