Wire & Transfer Release Control

Architecture

Key specifications

What it does for you

An operating entity releases outbound payments -- wires, ACH and internal book transfers -- and a wire is irreversible the moment it posts, so every packet has to clear a set of preventive controls before the wire room lets it leave. Two different people have to have signed it with a complete, correctly ordered authorization; each signer has to be on the funding account's register and the amount within the authorizer's limit; the beneficiary has to match an approved template or a new detail has to have cleared a callback; the routing number has to pass its checksum and resolve to the named bank; the funding account has to exist and cover the amount; the packet must not duplicate a payment already posted; and it has to have moved through the three workflow stages in order. Three failures hide inside that, and none of them look wrong on a filled-in form. The same person moves the money end to end, or the packet is released before the second signature is complete. The money goes to the wrong account -- an off-template beneficiary, a changed detail released without a callback, or a routing number that names a bank it does not resolve to. And the release log drifts from the evidence, calling a packet releasable on a determination nobody recomputed. None of these are judgment calls. They are equalities, thresholds, date gates, membership tests and re-derivations -- an amount against a limit with exact >, a triplet against a stored template, a stated flag against its recompute -- which a deterministic control settles better than a folder of one-page forms passed to whoever staffs the wire room this week.

The seeded demo runs every control over every release-control file⁷. The CLI generates twenty-five fictional release-control files -- one clean baseline and one carrying each of the twenty-four planted defects -- then runs all twenty-three controls over each. The clean file returns PASS with no flags; every defect file returns REVIEW or FAIL and names the control it tripped along with the reason that control exists.

The authority limit and the funding balance are independent thresholds⁸. One defect file lifts a packet a single cent over the authorizing signer's dollar limit while leaving it well within the funding balance, so sig_within_authority_limit fails and fund_sufficient_balance does not; another drops an account's available balance below a scheduled wire drawn on it, so the funding check fails on its own. Each threshold is checked with exact > at its boundary, proving the two catch different failures.

The release determination is recomputed, not read back⁹. A defect file flips a packet's stated releasable flag to False and moves the release report's releasable and blocked counts along with it, so the summary and the report agree with each other and only a recompute can see the break. rpt_release_flag_recomputes rebuilds the flag from the signers, templates, routing and funding through the shared release kernel and fails, proving the summary is recomputed from the evidence beneath it rather than trusted as stated.

Functional block diagram

Instruction set

Benchmarks

Control characteristics

• Read-only: release-control files are parsed and never written back, so the engine cannot introduce the break it reports.
• Integer cents throughout, compared with exact > and ==; there is no tolerance band on an amount or a limit, and a cent over is reported as a break.
• An amount or limit that should be integer cents but is not produces an AMOUNT_INVALID finding contained to the one row it was read on, rather than being coerced into the number the engine is meant to audit.
• One release kernel: the controls and the generator share wire_engine.release, so a releasable determination cannot disagree with the data that produced it.
• Segregation of duties is checked as identity and completeness: two distinct signers, both signer and date fields present, and the authorization dated on or after initiation.
• Deterministic and byte-stable: same inputs produce the same findings in the same order, with no timestamps or absolute paths in any output.
• Absent evidence is never a passing control; a missing artifact fails completeness rather than letting the controls that read it pass unread.

Operating limits

• The engine never releases a payment, initiates or authorizes a wire, places a callback, contacts a bank or a beneficiary, or writes to a source artifact. It reads the release-control file and stops.¹⁴
• It reads the eight artifacts the release record emits. It does not connect to a bank, a payment rail, a general ledger or a wire-transfer system, and it books no cash entry -- where the transfer lands in the ledger is a separate engine's question.¹⁵
• It proves a packet clears the mechanical gates -- two distinct authorized signers, an approved or called-back beneficiary, a resolved routing number, a funded account -- not that the beneficiary is the party the entity truly meant to pay or that a callback actually reached the counterparty. That judgment is the wire room's.¹⁶
• It checks the amount against the authority limit and available balance the file carries; it does not decide whether that limit is the right one for the signer or whether the balance on file is current as of release.¹⁷
• It takes the routing directory, beneficiary templates and posted log at face value: it confirms the packets reconcile against them, not that a bank-directory entry is real or a posting actually settled. All shipped data is fictional and the release period is set in a fictional future.¹⁸

See it run

Integration

Distribution: public repository, MIT license.