Franken-core: AI Agents and Programmable Money Force Core Banking Overhaul

Dharmesh Mistry's June 26, 2026 FinTech Futures article calls the patchwork of legacy cores, fintech layers, and tokenized-deposit infrastructure a Franken-core. His argument is that an agentic economy with AI agents making billions of micro-transactions on programmable rails creates a scale and control problem for architectures built by continuous adaptation. The claim is commentary, not a measured forecast of bank-wide production volume.

The engineering question is more specific. Which tasks can an agent plan and negotiate, which actions require deterministic policy checks, and which system owns the final settlement record? The FinTech Futures source article, AP2 documentation, and the IMF analysis of agentic payments point toward a layered design instead of an autonomous ledger that is allowed to infer authority.

This article treats Franken-core as a useful metaphor for accumulated coupling. It does not claim that AI agents have replaced bank ledgers, that programmable money has reached production scale across the banking sector, or that a particular institution must choose a vendor or a migration date.

What You'll Learn

• What the Franken-core metaphor identifies in legacy banking architecture
• How AP2 and verifiable mandates separate agent intent from payment authority
• Why probabilistic reasoning needs a deterministic authorization boundary
• Which migration signals senior developers and bank architects should measure

What the Franken-core Argument Actually Says

Mistry's June 26 article describes three related conditions. Banks adapted existing cores for new channels. They then added fintech layers and may run tokenized deposits through parallel infrastructure. The next pressure comes from AI agents that can discover services, negotiate choices, and initiate machine-speed payments. The article calls this an architectural destination problem rather than a request for a big-bang replacement next quarter.

The distinction matters because a second core can be either a controlled migration stage or another permanent dependency. The difference is not the label. It is whether the bank has a target state, measurable exit criteria, ownership, and a way to reconcile balances and policy decisions across both systems.

For adjacent AI infrastructure context, see the site's Big Tech AI demand analysis. It provides a separate view of infrastructure pressure and should not be treated as evidence that banking transaction volume has already reached the levels described in the commentary.

Why Agentic Payments Change the Interface

Traditional payment systems assume that a person or institution directly initiates an instruction through a trusted surface. An agentic system changes the interaction. A user may provide an objective, constraints, and an approval policy while an agent searches, compares, negotiates, and prepares an action. The agent can be useful without becoming the final authority.

The Google Cloud AP2 announcement identifies three questions that must be answered when an agent acts on a user's behalf: authorization, authenticity, and accountability. The AP2 design uses cryptographically signed mandates and verifiable credentials to create evidence of the user's instruction. This is a control-plane response to an interface problem. A payment processor cannot safely infer authority from a model's text output.

That boundary also changes observability. A conventional payment log can often point to a human click, an account, an instrument, and a policy result. An agentic flow needs the objective, constraints, tool calls, identity, mandate, merchant response, final cart, and payment result to be linked into one audit trail. Without that chain, a disputed transaction becomes a reconstruction exercise.

The site's AI accounting agents and stablecoin-finance coverage gives adjacent context on automation in financial operations. The architectural lesson is the same. Automation must expose its authority and evidence boundaries instead of hiding them behind a single agent label.

Why Core Banking Has a Deterministic Boundary

Large language models and other agentic systems are probabilistic. They can produce different outputs for similar prompts, call tools in different sequences, or misunderstand an ambiguous instruction. Payment and settlement infrastructure has a different contract. It needs deterministic rules, predictable state transitions, legal finality, reconciliation, and clear failure handling.

The IMF's April 24, 2026 paper frames this tension directly. Its analysis separates intent formation and orchestration from authorization and control, then from settlement. The framework is a conceptual model, not a universal implementation, but it provides a practical review question: where is adaptive reasoning allowed to operate, and where must the system enforce fixed policy?

A bank does not need to prohibit agents from making recommendations or preparing payment plans. It does need a deterministic gate before an irreversible action. The gate can check identity, mandate scope, amount, counterparty, velocity, sanctions, available funds, fraud signals, and human-approval requirements. A failed check should produce a structured rejection or a bounded revision request, not an unlogged improvisation.

How AP2 Binds Agent Intent to Payment Authority

AP2 is an open protocol for agent commerce. Its documentation describes AP2 as an extension for A2A and a companion to MCP. The protocol does not turn an AI model into a bank. It defines messages, credentials, mandates, roles, and evidence that can let compliant agents and merchants transact across payment methods.

The AP2 documentation describes two primary mandate types. A Checkout Mandate captures the purchase details negotiated between an agent and a merchant. A Payment Mandate authorizes payment against a specific instrument. Both have open and closed stages. The open stage records constraints or goals. The closed stage binds authorization to a finalized checkout or amount. This structure is more precise than asking whether a model is trustworthy in the abstract.

Google Cloud describes an Intent Mandate and a Cart Mandate for human-present and human-not-present flows. The naming differs from the AP2 documentation's Checkout and Payment Mandates, but the control objective is consistent. The system needs verifiable intent, a bounded action, and an audit trail connecting the two.

AP2 supports cards, stablecoins, and real-time bank transfers in the Google Cloud description. That does not mean all payment rails share the same settlement risk. A bank still needs rail-specific policy, liquidity, dispute, and compliance controls.

What Programmable Money Adds to the System

Programmable money is often described as money that carries conditions or can be routed through code. In an enterprise design, the useful question is not whether money is programmable. It is which conditions are enforced by the asset, which are enforced by a wallet or account, and which remain in a bank's policy layer.

Agentic payments make this separation visible. An agent might search for a service, create an order, and propose a payment. A programmable control could restrict the payment to a merchant class, a budget, a time window, or a settlement condition. The core ledger still needs to record balances, holds, finality, reversals where permitted, and reporting obligations.

The site's stablecoin infrastructure funding analysis is a useful adjacent link for readers tracing payment-rail design. It does not prove that stablecoins replace bank deposits or that a programmable asset automatically solves compliance. Programmability moves some controls closer to execution, but it also creates code, upgrade, key-management, and incident-response responsibilities.

Where AI Agents Belong in a Three-Layer Model

The IMF's three-layer framework is a strong starting point for a senior-developer review. Layer one handles intent and orchestration. Layer two handles authorization and control. Layer three handles settlement. A production architecture may use different product names, but the separation creates a testable ownership map.

The practical rule is simple. The agent can propose. The policy engine can decide whether the proposal is authorized. The settlement system can execute an authorized instruction. If the agent is allowed to skip the policy boundary, the bank has not built agentic banking. It has attached an unbounded decision-maker to an irreversible system.

For an adjacent example of AI and market infrastructure moving together, see the site's technology-market analysis. The link is contextual and does not substitute for a payment architecture review.

Why a Second Core Is Not a Migration Strategy

Mistry's source argues that a second core can be a legitimate bridge for tokenized deposits. That can be useful when the bank needs to isolate new capabilities, test settlement paths, or learn from a controlled pilot. It becomes a problem when the bridge has no trigger, no owner, and no reconciliation design.

A second core creates its own failure modes. Accounts can diverge. Product rules can be implemented twice. Limits can be interpreted differently. Operations teams can lose track of which system owns the authoritative state. A bank can also mistake a successful pilot for an enterprise-ready control plane while leaving the original ledger untouched.

The migration plan should state the destination architecture, the sequence of capability moves, the trigger for consolidation, and the risk budget for both staying and moving. Those are the four planning components Mistry identifies in the June 26 commentary. The plan should also define how an agent's mandate is represented across old and new systems during the transition.

What Banks Need to Measure Before Replatforming

Senior developers should resist a vendor-first discussion. Before choosing a new core, measure the current dependency graph. Record which products write to which ledgers, which systems calculate balances, where sanctions and fraud checks run, how exceptions are handled, and which APIs are used by channels or partners. The goal is to reveal coupling and ownership, not to create another inventory document.

Then measure the agentic workload as a set of control requirements. A payment request may require a search trace, a mandate, a policy decision, a hold, a settlement call, and a reconciliation event. Each step should have an idempotency key, a timeout, an owner, and a retry policy. If the workflow cannot be replayed safely, it is not ready for autonomous execution.

The relevant performance metric is not a single transaction-per-second number. It is the system's ability to preserve correctness under retries, partial failure, concurrent mandates, delayed callbacks, account holds, and policy changes. Load tests should include burst behavior and degraded dependencies. The test report should capture both throughput and evidence quality.

Failure Modes That Need Explicit Controls

Agentic banking introduces failure modes that are partly technical and partly institutional. An agent can misread a user's objective. A merchant can return ambiguous data. A policy service can be unavailable. A model or tool can change version. Two agents can act on stale state. A payment can succeed while a downstream ledger write times out.

The IMF highlights authorization traceability, opacity, correlated behavior, cybersecurity, legal questions, liability, and operational resilience. These risks map to concrete controls. Mandates limit authority. Identity frameworks bind actions to actors. Policy engines enforce scope. Audit trails preserve evidence. Human review can be required for thresholds or exception classes. Circuit breakers stop repeated failures.

Testing must cover more than happy-path purchases. Include revoked authority, duplicated messages, replayed mandates, changed prices, unavailable fraud services, inconsistent balances, compromised tool credentials, and a merchant that acknowledges an order but not a payment. A bank should be able to explain why a payment was allowed and how it would stop the same condition from repeating.

What the Protected Article Gets Right and Wrong

The protected article is right that legacy complexity can become a systems constraint when every new capability is added as another layer. It is right to focus on the relationship among AI agents, programmable money, and core-banking architecture. It is also right that a migration conversation needs a destination rather than an endless series of patches.

The original body is too definite when it says AI agents will replace traditional ledgers or that billions of daily micro-transactions already exceed what every core architecture can process. It also includes survey percentages, named bank examples, and direct quotations that were not all independently fetched in this workflow. The safer technical conclusion is that agentic payments create a new control and observability requirement that banks should test before production expansion.

For another verified agentic-technology topic on the site, see the Bittensor roadmap analysis. Its network-governance subject differs, but the need to separate claims from implementation evidence is shared.

A Senior-Developer Implementation Checklist

Start with a typed intent object and a stable correlation ID. Store the user objective, constraints, agent identity, tool calls, model version, and policy context. Convert that intent into a mandate that can be verified independently of the model. Do not pass raw model text directly to a payment endpoint.

Make the authorization boundary explicit. It should own identity checks, mandate validation, counterparty policy, amount and velocity limits, sanctions and fraud controls, approval state, and a decision record. Settlement should consume only an authorized instruction and should be idempotent. Reconciliation should be able to match intent, authorization, settlement, and ledger state even when an external service fails midway.

Finally, define a migration trigger. It can be based on maintenance cost, failed change lead time, product constraints, control coverage, or an inability to support a tested workload. The exact trigger is institution-specific. The engineering requirement is that someone owns it, the evidence is reviewable, and the bank can act before the second core becomes another permanent limb.

Readers interested in a separate banking-infrastructure funding example can review the site's stablecoin infrastructure funding article and compare its business context with the control-plane questions here.

Conclusion: Replace the Monster Without Repeating It

Franken-core is a useful warning when it points to accumulated coupling, duplicated controls, and unclear ownership. It becomes unhelpful when it implies that one new ledger, one AI model, or one programmable-money rail will solve the whole problem. The durable design is layered. Agents handle bounded intent and orchestration. Deterministic policy systems authorize. Settlement rails execute. Ledgers reconcile and preserve finality.

AP2 gives the payments layer a concrete vocabulary for mandates, credentials, intent, checkout, and accountability. The IMF supplies a governance lens for separating probabilistic decision making from deterministic execution. FinTech Futures adds the migration question: what is the destination, what is the sequence, and what triggers the move?

The next step is not to announce that the old core is dead. It is to measure where it fails, encode authority in verifiable controls, test the new workload under partial failure, and assign ownership for the migration path. For a separate view of banking-market infrastructure, see the site's banking-markets coverage. That is how a bank can build toward agentic payments without turning its next architecture into another Franken-core.