More and more, a bank's everyday decisions are made by software in a fraction of a second. MidFirst can always say what it did. The harder question, months later, is whether it can quickly show exactly what happened and why.
Maria's request travels the same path either way. Software checks the bank's rules and the bank acts in a fraction of a second. The only difference is what is left behind for later, when she or an examiner asks what really happened.
The proof of what happened is spread across separate systems and screens. Months later, answering Maria means hunting through several places and stitching the story back together by hand. It can be done, but it is slow and hard to hand to a colleague or an examiner.
At the instant the decision is made, Hive creates one sealed, time-stamped proof record of what the system saw, which rule it used, what it decided, and what happened next. Answering Maria later means opening a single record, not a search party.
A proof record is a sealed, time-stamped record of what the system saw, which rule it used, what it decided, and what happened next. It is created at the moment of the decision and cannot be quietly changed afterward: if one fact is altered, the seal breaks. It is not a store receipt, and it does not decide whether the outcome was right. It only preserves, in a way anyone can check, what actually happened. Later on you may see us call it a signed receipt; it means the same thing.
Want the depth behind this? Keep scrolling for the live demos, or read the full strategy paper.
Adding a proof record changes nothing about who runs the bank. MidFirst does everything it does today. Hive only keeps the record.
MidFirst serves the customer, sets the policy, makes the decision, holds its security keys, and moves the money.
Every part that matters stays inside the bank, exactly as it works now. Maria is MidFirst's customer, and the decision on her account is MidFirst's decision.
Hive never touches customer funds or decides what the bank should do.
Hive only preserves an independent, sealed record of what happened, so it can be checked later without having to simply trust anyone's word, including Hive's own.
Maria's problem is one example. The larger change is that customers will increasingly act through software. Here is what that means for MidFirst, from the bank today to a realistic path forward. Each panel stands on its own.
The bank customers already trust
Customers trust MidFirst to protect and move their money across the products they use every day.
The bank safely stores and moves money.
Customers start acting through AI agents
More customers now let AI agents handle money tasks for them.
The bank sees the request, but not who authorized it or on what terms.
The request arrives; the authority behind it is unclear.
The same bank, now with proof
MidFirst still serves the customer, makes the decision, holds its security keys, and moves the money. Hive adds one thing.
Hive provides the proof. MidFirst provides the relationship.
Today compared with tomorrow
The proof layer records and seals what each agent was allowed to do and what actually happened.
A thin proof layer connects AI agents to the bank.
From managing money to managing trust
MidFirst can become a trusted place where people and their agents do business, governing more than money alone.
The bank governs money, identity, permission, and proof together.
A repeatable, verified loop
Every trusted action feeds the next one.
From uncertainty to verified execution
Hive turns uncertainty into something the bank can prove.
What could set a bank apart
Trust and authority could become the real differentiators.
A realistic path, one step at a time
Start with one low-risk workflow, then expand as the rules mature.
One path starts this year and changes nothing about how MidFirst decides. The other is a deliberate build toward 2032, as the rules for agentic banking are written.
These are workflows MidFirst already runs. A signed receipt attaches alongside the existing workflow without changing the decision path. Each one maps to MidFirst's own public surface, with cautious language: the receipt proves an event was recorded, not that the underlying decision was correct or compliant.
This is a directional, multi-year build path. Nothing here is a present product commitment, and every milestone assumes rules that are still being written. Where a product name is used, treat it as an internal working label pending trademark and regulatory-language clearance.
Read the full strategy, including the roadmap and regulatory guardrails.
Pick a part of the bank. An action gets asked for, a MidFirst rule is applied, the action happens or is held, and a signed receipt is made. Nothing here is real MidFirst data. It is made up to show how the service works.
Press Run this decision to watch the receipt get stamped.
This is the shape of the "build toward 2032" idea, made small. A customer grants an agent a narrow, revocable spending authority. The agent asks to pay a bill. MidFirst's rule checks the limit, allows it, and a receipt chains the grant to the action. Made-up example. Not MidFirst data.
Press Run the delegated payment to build and check the authority chain in this tab.
This builds a real signed receipt for a bank decision, checks it in your browser, lets you break one byte and watch the check refuse it, re-checks pasted evidence, and re-verifies a published 5,000-receipt soak test. Everything runs in this tab.
The signing engine is bundled and served from this same site. After the page loads it makes zero outside calls except two same-site file reads it names out loud.
In-browser · offline The verifier never leaves this page except to read its own sample and soak-test file from this site.
Everything above proves what a decision was, after it was made. These seven do the opposite. They put the rule itself on the record, signed, before the action runs, so that afterwards nobody can rewrite what the rule was.
The hard part of a servicing or model-risk exam is almost never that a log is missing. It is that the log and the policy do not line up, and the policy was never versioned, so there is no way to show which rule actually governed one decision on one day. These seven fix that end of the problem. Each one signs the rule, the scope, or the boundary in advance and timestamps it, so the version in force at the moment of the decision is a fixed, checkable artifact rather than an argument.
The signing and verification core of each of these seven is live and you can check it. The enforcement hook is not. None of them currently proves that a kernel hook blocked an action, that a classifier measured a payload, that a policy engine authorized a change, or that a probe was wired into a running model. Each records an identifier and an evidence digest supplied by the caller, and signs it. That is pre-commitment, and it is worth having, but it is not interception. Wiring the enforcement leg into a real runtime is exactly what a design partner engagement builds, and it is the scope we would propose to MidFirst. Every one of these limits is published in our canon registry, per primitive, in the same words.
You approve a model inside a specific runtime. Then it runs for months. Provenance-Bonded Sandbox signs a manifest of that runtime before the work starts, so the environment you signed off on is fixed in the record rather than remembered. Model risk gets a dated, signed statement of what was approved instead of a screenshot from deployment day. The kernel-level hook that would detect drift on its own is integration work and is not built.
Every guardrail is a control, so every change to a guardrail is a control change. Refusal Ledger keeps a signed append-only chain of every mutation to what an agent is forbidden to do. You can show which version of the rule governed one specific decision, and show that nobody loosened it quietly and dated it backward. The chain proves the sequence of rule changes. It does not itself prove that a policy engine authorized any one of them.
Howler is built to sit in the model's own loop and raise a signed alert on three things: the agent drifting off the task it was given, the agent reaching for a capability it was never scoped for, and data entering the context that should never have been there. The alert is itself a receipt, so the alarm is evidence rather than a log line. The receipt type is live today. The probe has not yet been wired into a running model, which is what a design partner engagement does first.
Telling a model not to call an outside service is not a control. Perimeter Bond commits the allowed reach in advance, underneath the application, and signs that commitment so the boundary an examiner is shown is the boundary that was set before the run, not one described afterward. The interception layer that would refuse an outbound attempt in real time is integration work and is not built.
A bank already treats 4:50pm Friday differently from 10am Tuesday. Diurnal Bond turns that instinct into arithmetic. The risk regime and the attestation count it demands are declared and signed ahead of time, so the standard that applied at 4:50pm Friday is a signed fact rather than a recollection. It is dual control that knows what time it is. Making the higher count block the action is integration work.
Egress Bond pre-commits a cap by class of data. Zero customer-identifying rows. No more than a set number of rows of anything else. The commitment is signed before the run, so if a breach happens later the argument is about a fixed, dated number instead of about what everyone intended. The classifier that would measure the actual payload against that cap is integration work and is not built.
When something goes wrong, access to the evidence should not rest on one administrator. Forensic Rail signs a bonded credential naming the several independent approvers behind it and the bounds of the session, and records the analysis so it can be replayed byte for byte. Outside counsel or an examiner can reproduce the finding instead of accepting the first responder's word for it. The credential records the bound. It does not itself hold the session inside it.
Each of the seven has its own verification route on the live rail, and verification is open. No key, no account, no call to us. Post a receipt to POST /verify/usap-howler, /verify/usap-egress, /verify/usap-perimeter, /verify/usap-pbs, /verify/usap-refusal, /verify/usap-diurnal or /verify/usap-forensic at proof.thehiveryiq.com and you get back a gate-by-gate verdict your own engineers can read. Issuing a receipt is the other half and it is deliberately not open: minting requires a bearer token and fails closed, so a caller cannot mint themselves a stronger verdict than the service computed.
The signing and verification core of all seven is live on the Hive rail right now and the verification side is open to anyone. That part is real and you can test it in front of your own team without talking to us.
The enforcement side binds to the runtime where the agent actually executes, and it is not built. Standing it up at MidFirst is integration work rather than a switch we flip. We would rather say that here than in the third month.
All seven are patent pending. None of this describes a deployment at MidFirst or at any other bank.
Everything below is drawn from public documents and linked to the primary source. Each one is matched to a primitive that is live on the rail right now, with the limits of that primitive stated in the same breath. Nothing here describes work done for MidFirst.
/verify/sequence-attestationHUD OIG report 2025-KC-1001, issued 28 January 2025, is titled MidFirst Bank Misapplied FHA's Foreclosure Requirements. The finding is not a missing document. It is that loss mitigation was not completed before foreclosure was initiated or continued, in an estimated 1,038 of 7,363 loans, 14.1 percent of 2022 filings, against roughly $185.9 million of at-risk unpaid balance. No claims were paid, so the exposure was procedural rather than realized.
A procedural finding about order is the one thing a receipt can close cleanly. Sequence Attestation folds a set of events into a root in exactly the recorded order and brackets that root between two independent external time anchors, including a public blockchain block hash. An examiner can check the order offline, against a public key, without calling the bank and without being given the loan file. The next audit asks a different question when the answer is a signed artifact rather than a screen share.
MidFirst Bank and Midland Financial Co. are named in MDL Order No. 21 in the MOVEit litigation, MDL No. 3083 before Judge Allison D. Burroughs in the District of Massachusetts, centralized in October 2023. Worth being precise about what is pled: no court document names the vendor as the sole cause, and the allegation runs to the bank's own vendor-oversight. The missing artifact is not a record of what the vendor did. It is a record of what the bank required of the vendor, fixed in advance.
Egress Bond and Perimeter Bond sign that requirement before the run: the class of data that may leave, the volume cap, the reach that is permitted. When something breaks later, the argument is about a signed, dated commitment instead of a reconstruction.
/verify/supersessionEscrow analyses, payment application, force-placed insurance and Reg X disputes surface years later, usually after the loan has moved and usually after the system that made the decision has been retired. The record of what was decided, and under which policy version, rarely survives the migration intact.
A signed receipt does not depend on the system that issued it still existing. It verifies against a public key, offline, with no database and no vendor in the loop. Supersession Receipt handles the case that actually causes the arguments: it proves that a named later record corrects specific earlier ones as of a stated effective date, for a stated reason and scope. A corrected escrow analysis stops being a contradiction in the file and becomes a documented, signed correction.
/verify/delegation-linkVisa's agent-driven commerce product is in pilot with select partners, and Mastercard with Datos Insights forecast 324 million chargebacks globally by 2028, before agent volume is counted at all. That last figure is a vendor forecast rather than a filing, and is offered as context only. The burden question is old and settled: under 15 U.S.C. 1643(b) the card issuer bears the burden of proving a use was authorized. What is not settled is what authorized means when the thing that decided was software. No agent-specific liability statute exists and the network rules are private contract, so this is an open question rather than a rule anyone can point to.
That is precisely why it is worth receipting early. Authority Delegation proves that a delegation's scope, constraints, validity window, and depth do not exceed what its parent grant allowed, and that its issuer signed it inside that window. An agent transaction stops being an assertion and becomes a chain a dispute analyst can walk. A small card book is the cheap place to learn this.
/verify/imprimatur-clearanceThe FBI's 2025 IC3 report puts business email compromise losses at $3.05 billion across 24,768 complaints, up from $2.77 billion the year before. The control almost every bank relies on is a callback, and the evidence that the callback happened correctly is a note written by the person who made it.
Imprimatur signs a clearance before the action runs: it records that four named preconditions were evaluated and combined exactly as recorded, and that a precondition root recomputes from those four leaves. Paired with a delegation chain, the question of who authorized a payment and under what standing authority has a signed answer that does not rest on one employee's recollection.
Every linked figure above comes from the primary document it links to, not from press coverage. MidFirst's FHA servicer position is taken from the bank's own statement inside the OIG audit, where it describes itself as the twelfth largest FHA servicer by loan volume as of 31 August 2024. The one unlinked number, the 2028 chargeback forecast, is a published Mastercard and Datos Insights projection rather than a filing, and is labelled as such where it appears. Where a widely repeated number could not be found in a court document, it has been left off this page rather than repeated.
You do not need any of this to understand the value. It is here for the people who want to look under the hood. Each row is a plain benefit first, with the Hive part named as a small label, and marked help now or help next.
See the full canon of Hive primitives. The strategy page explains where each one is help now and where it is help next.
In plain words: MidFirst holds the pen that signs. Hive never holds your money and never holds your keys.
The bank keeps the private key that stamps its receipts. Nobody else can sign in MidFirst's name, and the key never leaves the bank's own hardware. The signature is the bank's, not Hive's.
Hive gives you the way to make and check receipts. It does not touch customer money, it does not hold your keys, and it does not read the contents of a customer's message. Each decision is recorded as a one-way fingerprint, never the words.
How regional and national banks can become the trusted operating system for AI-driven commerce. It reads like an internal banking strategy MidFirst could circulate: the shift, the architecture, five new banking products, why stablecoins alone are not enough, a help-now map, a phased roadmap, and the regulatory guardrails, all with primary-source citations.
Charter 001 is an illustrative invitation: a one-of-one genesis concept for the first bank that chooses to make its automated decisions independently provable. It is shown here to picture the idea, not to reserve a market or lock out a category.
This concept does not exist until MidFirst affirmatively participates. There is no signed deal, no category lockout, no customer status, no pilot, and no endorsement. Hive does not promise broad exclusivity. This page does not state or imply that MidFirst is a customer, partner, pilot, or endorser.
A provable bank is one that can hand over proof of its automated decisions, checkable by anyone, offline. Naming the idea does not imply any agreement. The seat is open until someone affirmatively takes it.
These receipts add an independent comparison of two bank records and a precise record of a screening decision beside the delegation, limits, and agent authority this page already describes. They are deployed and open to verify, so the runs below are live checks, not mocks.
When an agent acts under a customer's limits, two systems may later need to compare what they recorded. This receipt fixes the named records, the fields, the observation times, and the cursor for each record. Separate registered keys commit fingerprints of each record, then the service recomputes the comparison. A difference is visible to your fraud, operations, legal, and risk teams without exposing customer balances or account details. That can shorten the work of locating where two accounts of an action stopped matching.
What it does not do. It does not reveal positions, balances, holder identities, or account identifiers, and it cannot confirm that either fingerprint accurately represents the record named because it grants no access to that record. It does not choose the correct record, assign fault, determine whether the action or settlement was proper, or carry out or reverse a transfer, and a late window says only that the observations were too far apart to decide.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
This receipt preserves the screening context for a customer, agent, or counterparty action. It binds the screening engine, rule version, named lists and their versions, screening time, validity period, and declared result. The identifier and list entries are committed as fingerprints, so the record can be reviewed without exposing them. Your compliance, fraud, and operations teams can see which screening run produced the result beside the authority and limits that shaped the action. That makes the historical record easier to hand from one bank team to another.
What it does not do. It does not show that any list is complete, accurate, current, or free of omissions, decide that a counterparty is actually restricted, catch every false negative, catch an engine that clears a match it found, or assess the adequacy of the program, its thresholds, lists, or validity period. It does not identify the counterparty, expose a list record or match score, prove custody of the commitment key or window secret, or admit, block, freeze, reverse, settle, report, or provide a legal, regulatory, or compliance conclusion about any transaction.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Every run above posts a verified request body from this domain to the open verify route and prints what came back. The example receipts are signed with published example keys, so verify reports key_trust example_registry. That is on purpose. Nothing on this page is a production issuance, a customer record, or an endorsement. Patent Pending.
Each link opens that entry in the canon implementation explorer, where its schema, mint route, open verify route, auth requirement and implementation state are stated. The state shown here is read from the same registry file the explorer renders from, so the two cannot drift apart. Nothing here implies a customer, a deployment or an endorsement.
Search the explorer for MidFirst use case