Who Can Act, Which Record Governs, and How Do You Recover?

Financial integrity rests on three linked questions: Who or what can act? Which record governs? How does the institution recover when actions or records go wrong?

These questions apply whether the actor is a person, conventional software or an AI agent. Connected software makes them more urgent because it can assemble an instruction, use a credential, call another system and continue through multiple steps. The system can move faster than a control designed to review one screen, one request or one application at a time.

Approval is not authority

A proposal, approval, authorization and execution are different events.

A system may propose a payment or trade. A person or automated check may approve what is presented. A separately enforced control must still decide whether the actor has authority for the actual account, beneficiary, instrument, value and time. Only then should an execution service cause the external result.

The distinction is familiar in finance. A person can prepare a payment without being able to release it. A trading system can construct an order without permission to send it. A reconciliation process can identify an error without authority to rewrite the ledger.

NIST argues that software agents need distinct identities, credentials and entitlements.[1] That makes delegation visible and revocable. An agent should not silently inherit a developer’s, trader’s or service account’s complete authority merely because it performs work for that principal.

Correct execution can carry an invalid instruction

A protected execution mechanism can work exactly as designed and still carry the wrong business instruction.

Bitget reported approximately $387.5 million in attacker-directed transfers in September 2026. Reporting on the chief executive’s account said spoofed transaction information entered the authorization-signing process while private-key compromise had been ruled out.[2][3] No public independent forensic report accompanied that explanation at the cited cutoff, and the event was not reported as an AI incident.

Its control lesson is narrow and important. A valid signature can establish that a particular key signed a particular message. It does not, by itself, establish that the amount, destination, asset or underlying instruction was genuine. Technical execution and business authorization must be checked separately.

That same mismatch can occur when an approval screen shows a description rather than the resolved beneficiary, when a policy service evaluates a summary rather than the final API request, or when several individually permitted steps combine into a prohibited outcome.

Which record governs when systems disagree?

A completed action creates records in more than one place: the initiating application, approval system, execution venue, bank, custodian, administrator, transfer agent, depository or settlement service. Those records can be delayed, incomplete or inconsistent without any one display obviously looking broken.

An authoritative record is the record accepted as controlling for a particular purpose when systems disagree, subject to the relevant legal, contractual and market rules. It is not necessarily the first dashboard to return after an outage.

A September 2026 shared-core banking outage illustrates the problem without establishing record corruption. Affected credit unions reported unavailable online banking, last-known balance information for some decisions, held electronic transactions and sequential restoration across more than 300 institutions. The institutions attributed the outage to equipment and cooling failure, not a cyberattack.[4][5] The event shows how a common provider failure can leave institutions and customers working from stale or limited information.

The operational question is not simply whether data exists. It is which record controls cash, ownership, valuation, instruction status and settlement—and which independent evidence can reveal that the controlling record is wrong.

Detection, interruption, reversal and finality differ

A control that detects activity does not necessarily interrupt it. An interruption does not necessarily cancel actions already queued or transmitted. A reversal does not necessarily erase every consequence.

Useful incident timelines therefore include more than the first alert. They identify when activity began, when a machine-detectable signal appeared, when a responsible person received it, when effective authority was withdrawn and when the destination confirmed that activity had stopped.

Financial actions can also acquire finality. CPMI-IOSCO principles call for clear and certain final settlement in financial market infrastructures.[6] Even where an institution can correct an entry or make a customer whole, it may still need to resolve liquidity, tax, disclosure, allocation or third-party consequences created by the original action.

Restored service is not clean recovery

A service can be available while its state remains untrustworthy. Clean recovery requires evidence that material identities, permissions, transactions and records are complete, correctly ordered, free of unintended duplication and reconciled with sufficiently independent sources.

FFIEC guidance addresses integrity across production data, backups and replicas, including the danger that corruption can propagate into recovery copies.[7] Recovery therefore cannot consist only of restarting the same environment. It must establish which state is authoritative and why.

A standing institutional test follows:

Identity: Which person, agent or service acted?
Scope: What was it allowed to do, for which purpose and period?
Route: Which tools, credentials, providers and downstream systems carried the action?
Independent enforcement: Which limit could refuse the action outside the actor’s own reasoning or session?
Evidence: Which record survives beyond the acting or affected system’s control?
Interruption: Who can revoke credentials, freeze queued work and confirm cessation?
Reconciliation: Which records must agree, and who owns an exception?
Restart: What evidence must exist before ordinary processing resumes?

Financial Integrity Watch covers incidents and decisions where those questions connect to money, records, transaction authority, custody, settlement or recovery. The focus is not technology in the abstract. It is the chain from instruction to consequence, and the evidence needed to trust the result.

Sources

Methodology · Corrections · Archived original