The Third Leg, Close to Home

The first Counterpart demonstration used Bitcoin because it makes the cost of two copies impossible to ignore. A transaction on a public network and a ledger entry inside an institution are plainly different things. Somebody has to connect them, explain the confidence of that connection, and deal honestly with reversals.

This video starts closer to home: two entities on the same Control Plane. ACME Services raises an invoice. Beta Retail sees it as a proposed payable and accepts it. Both sides settle the same advice.

One database is not an objection to ignore

It is a fair objection: this first link uses one database. It is not a federated protocol, and it does not pretend that two entities operated by the same Control Plane have the independence of two companies running their own infrastructure. That is a later boundary, where a signed exchange between systems matters.

But a shared database does not have to mean one party can silently rewrite the other's books. Each entity keeps its own journal, chart of accounts, permissions, and posting authority. The provider's posting creates a canonical advice and a pending clearing position. On the customer side, the advice is visible but cannot post to a real payable merely because it arrived. Beta must acknowledge it. Only Beta can move Beta's books.

That distinction is the useful part of the INTRA link. The transport is local, so there is no file to export, no API polling loop, and no overnight matching job. The accounting control remains local, and the state of the relationship is available as soon as either party acts.

A shared database still needs evidence

Convenience must not become a reason to trust mutable rows blindly. MGL folds posted ledger entries into a Merkle Mountain Range—an append-only Merkle forest, not one monolithic tree. Each anchor commits to the ordered history seen so far. Anchors are HMAC-chained with key material held outside the tenant database, and they are mirrored to the control database.

That is tamper evidence, not magic immutability. A privileged writer can alter a row, but cannot make a later replay reproduce the anchored history without also defeating the anchoring controls. A deleted or reordered anchor leaves a different kind of evidence. The integrity check turns a quiet database edit into a discrepancy that can be found, localized, and investigated.

This is precisely why the first ring is worth having. It does not claim to solve the independent-counterparty problem. It makes the shared platform a bad place to hide an accounting alteration while the operational model remains simple enough for intercompany receivables and payables.

Reconciliation can happen when the event happens

The deeper idea is not specific to invoices. ISO 8583 gives payment systems their own evidence: an authorization, a reversal, a retrieval reference, a network lifecycle. ISO 20022 gives banks another vocabulary: payment identifiers and status reports. Those messages do not need to become a nightly file-matching exercise after they have already told us what happened.

Counterpart provides the common reference for that binding. The INTRA flow proves the state model locally; a later federated leg can bind an ISO 8583 transaction and its clearing or reversal to one counterpart state. An ISO 20022 payment or status message can advance the same kind of state for a bank-facing leg. The local ledger remains local; the canonical advice, its hash, and its receipts become the shared reference.

Then reconciliation stops being a report about yesterday. A missing message is a visible proposed item. A disagreement is a dispute, not an edited balance. A late reversal is a new state transition with a receipt, not a repair performed in a spreadsheet.

The video shows the smallest useful version of that idea: one invoice, two sets of books, one explicit acknowledgment. The next steps may cross systems, networks, and standards. The important design choice is already present: two legitimate views do not need two competing histories.