Infrastructure · Reconciliation

Books that agree
with themselves.

A balance is a cache of a ledger, and a cache can be wrong. Reconciliation is the scheduled work of proving it still is not — adding up the entries behind every balance, looking for records with no trace, and writing down the answer either way.

What is checked
Wallet balanceEach balance against the entries behind it
Orphan entriesTransactions carrying no ledger record
Settlement mismatchA batch against the payments it covers
Stuck paymentsSessions approved but never concluded

Each check can also be run on demand, and each run is attributable to the person who started it.

ChecksFour, plus integrity passes
CadenceDaily and hourly, scheduled
FindingsGraded, never auto-corrected
RecordsAgreement stored, not only drift
The worksheet

Every check is a pair.

Reconciliation does not move anything — it holds two things up against each other. The left of every row is something derived; the right is what it is supposed to agree with.

CheckWhat is derivedWhat it must agree with
Wallet balanceThe balance held on the wallet recordThe sum of the ledger entries behind it
Merchant balanceThe balance record, and the older aggregationWhat the ledger entries add up to
Orphan entriesA transaction that was recordedAt least one ledger entry for it
Settlement batchThe batch total, and the fees postedThe payments the batch claims to cover
Stuck paymentsA checkout session that was approvedA concluded outcome, one way or the other

Both sides of every pair are BINK records. There is no bank statement or processor file on either side, and none is claimed.

A run

Open, compare, close.

The run is recorded before the work starts, so a sweep that fails halfway is visible as a failed run rather than as no run at all.

  1. RunOpensA run is recorded before any comparison begins.
  2. CompareRecord by recordEach check reads both sides and computes the difference.
  3. ClassifyBy severityFindings are graded rather than treated alike.
  4. CloseWith a resultCounts, findings and a summary are written to the run.
The comparisons

Two sides, every time.

Every check has the same shape: something derived, something authoritative, and the difference between them. What varies is which pair is being tested.

These checks prove BINK’s records agree with each other. BINK does not ingest bank statements or processor files, and does not describe this as external matching.

A balance and its entries
A wallet balance is a cache. The check adds up the ledger entries behind it and compares the two — the only way to know the cache is still telling the truth.
Three ways at once
For merchant balances the comparison is three-sided: what the ledger says, what the balance record says, and what the older aggregation would say. Two agreeing and one disagreeing is far more informative than a single mismatch.
Transactions with no trace
A transaction that produced no ledger entries is a hole in the audit trail. It is looked for specifically rather than being noticed later.
Batches against payments
A settlement batch is checked against the sum of the payments it claims to cover, and against the fees actually posted for it.
Work that never finished
Checkout sessions that were approved but never concluded are found on an hourly pass, marked failed, and their reserved funds released.
What the engine does

Evidence, not reassurance.

The value of a reconciliation is not that it finds nothing — it is that you can prove it looked.

Agreement is recorded too

A run stores the balances that matched, not only the ones that did not. A report that only ever lists problems cannot tell you whether it looked at ten records or ten thousand.

Findings carry severity

Not every difference is equal. Each finding is graded, so a rounding artefact and a missing ledger entry do not arrive as the same kind of news.

Every run is a record

Type, status, duration, how much was examined, what was found and who started it — persisted per run, so the history of the checking is itself auditable.

Scheduled, not remembered

The sweeps run to a schedule rather than depending on somebody opening a console: a full pass and a treasury pass daily, and an hourly pass for stalled work.

One instance at a time

The financial sweeps take an exclusive lock before running, so a deployment on several instances cannot have two of them reconciling the same records at once.

Integrity checks alongside

Separate scheduled checks verify the ledger reconciles, that entries balance, that the audit chain is unbroken, that balances hold, and that the projection agrees.

Operational detail

Scope, stated.

What is compared
BINK records against other BINK records. Reconciliation here proves internal consistency — that the derived views still match the ledger they came from.
External statements
BINK does not ingest bank statements or processor settlement files, and does not describe this as matching against an external source. That capability does not exist today.
Resolution
Findings are recorded and graded, not auto-corrected. There is no automatic remediation, because a difference in a financial record is a question for a person, not a value to overwrite.
Stuck sessions
The one automated correction is narrow and conservative: an abandoned checkout session is marked failed and its reserved funds released. Any actual movement of money is left for investigation.
Cadence
Daily and hourly passes. This is scheduled reconciliation, not a continuous or real-time process, and BINK does not describe it as one.
Access
Running a reconciliation is an administrative action behind role permissions and network restrictions, and every run records the person who started it.
Operating history
BINK publishes no reconciliation volume, match rate or exception count. The checks are described by what they do, not by figures that would imply an operating record.
Operating it

Who runs this, and how.

Reconciliation is an operations surface rather than an integration one, which changes what matters about it: attribution, repeatability and evidence.

An operator surface
Reconciliation is not a customer-facing API. Runs are started and read in the admin console, behind role permissions and network restrictions.
Runs are addressable
Each run persists its type, status, duration, how much it examined, what it found and who started it — so a specific run can be cited later, not just described.
On demand as well
Any check can be run outside its schedule when something needs answering now, and that run is recorded the same way a scheduled one is.
Findings are read, not applied
A difference is surfaced with a severity for a person to act on. Nothing in the reconciliation path writes a correcting entry.
In practice

What the checks answer.

Answer “is the balance right”

Prove a wallet balance against the entries behind it rather than trusting the cached figure, and keep the proof that you checked.

Find a hole in the trail

Catch transactions that produced no ledger entries specifically, instead of discovering them later as an unexplained difference.

Close a period with evidence

Point at a run — its counts, its findings and its summary — rather than at an assurance that reconciliation happens.

Release funds stuck in limbo

Sweep checkout sessions that were approved but never concluded, marking them failed and releasing what they reserved.

In the platform

What it checks against.

Infrastructure

Every surface.

Reconciliation

Prove it, on a schedule.

Every balance checked against its entries, every run written down, and agreement recorded as carefully as disagreement.