Every MCP tutorial ends the same way: a weather tool, a curl command, a green checkmark. None of them tell you what changes when the tool you're exposing isn't getWeather(city) but initiatePayment(accountId, amount), sitting behind a Spring Boot service your bank already trusts with real money. This one's for the Java engineer who's been asked to turn that service into something an LLM agent can call — and needs the parts the tutorial skipped. 

Spring AI's MCP support is genuinely good — annotation-driven tool registration, auto-configured transports, sync and async server types out of the box. It's also, by default, a POST /mcp endpoint with no authentication in front of it, happy to hand an LLM agent a JSON-RPC interface to whatever you've annotated. That's fine for a demo. It's not a production posture for a bank, and the gap between the two isn't something the starter closes for you — it's the actual engineering work. What follows is that work, done once so your team doesn't have to rediscover each piece the hard way. 

Transport: the spec has already moved past what most people ask for 

MCP originally shipped with HTTP+SSE as its remote transport, and if you're planning a build around SSE, it's worth knowing that the protocol has moved on. The 2025-03-26 MCP spec revision deprecated HTTP+SSE in favor of Streamable HTTP, for reasons that show up quickly once you try to run SSE at scale: the original transport needed two separate endpoints — one to receive server-sent events, one to post client messages — which forces awkward coordination between connections that are supposed to represent one logical session. Long-lived SSE connections are resource-intensive to hold open across a fleet of instances, there's no built-in way to resume a dropped connection mid-stream, and the transport doesn't get the benefits newer HTTP versions offer. Streamable HTTP fixes this by consolidating everything onto a single endpoint that upgrades to streaming only when a response actually needs it, with the resumability and bidirectional communication SSE never had. 

Spring AI supports both, and the choice is a one-line config change, not an architectural one — which is exactly why it's worth getting right the first time: 

        type: SYNC              # or ASYNC, for reactive tool implementations 

        protocol: STREAMABLE    # SSE | STREAMABLE | STATELESS 

spring-ai-starter-mcp-server-webflux or -webmvc gets you either transport; the property is what switches it. Default to STREAMABLE for anything new — it's the current spec's baseline, and it's what any MCP client built against a recent SDK will expect. Keep an SSE-configured instance around only if you have a specific client you don't control that hasn't upgraded yet, and treat it as a compatibility shim with a retirement date, not the primary interface. STATELESS is worth a specific look for a banking backend beyond either of those: it drops server-side session state entirely, which is what actually lets a tool server scale horizontally behind a standard load balancer without sticky sessions — a constraint most core banking infrastructure already has opinions about. 

Tool registries: curate the surface, don't just annotate what exists 

The annotation model makes exposing a method almost too easy: 

    @McpTool(name = "get_transaction_status", description = 

        "Look up the status of a previously submitted transaction by ID.") 

            @McpToolParam(description = "Transaction ID", required = true) String txId, 

            McpSyncRequestContext requestContext) { 

        String callerToken = (String) requestContext.transportContext() 

        return transactionService.getStatus(txId, callerToken); 

 That's the right shape for a read-only tool. The trap is treating @McpTool as a convenient way to expose whatever's already sitting in a @Service class, one annotation at a time, until the tool registry has quietly become a mirror of your entire internal API surface. An MCP tool server for a banking backend should be built the way you'd build any other external-facing interface: a deliberate facade, narrower than what's behind it, where every tool is something you'd be comfortable explaining to an auditor as "yes, we intentionally let an LLM call this." That's the same ports-and-adapters instinct Java teams already apply at other integration boundaries — the tool registry is a boundary too, and it deserves the same discipline, not an exemption because the caller happens to be a model instead of another service. 

Two things follow from treating it that way. First, tool descriptions are part of your attack surface, not documentation — the entire tool schema, including parameter descriptions, is something a model reads and can be manipulated by, so it needs the same review as production copy, not whatever text was fastest to write. Second, per-request authorization has to run on the caller's actual identity, not the tool server's own service credential. The McpTransportContext pulling an Authorization header out of the incoming request, shown above, is what makes that possible — extract the caller's token at the transport layer and thread it into every downstream call, rather than letting the tool server hold one broadly-scoped credential and trust the agent to only ask for what it should. That distinction is what security guidance calls the confused deputy problem: a tool server that acts with its own privilege instead of enforcing the caller's is a privilege escalation waiting for the first agent session that gets manipulated into asking for something it shouldn't. 

Secrets handling: nothing hardcoded, nothing shared, nothing standing 

MCP's own security guidance is direct about where credentials go wrong in practice: tokens shared across servers instead of scoped per server, secrets sitting in plaintext config instead of a real secret store, long-lived personal-access-token-style credentials instead of short-lived ones scoped to a session. For a banking backend, none of that is a new problem — it's the same secrets-management discipline your existing services already answer to, and there's no reason the MCP boundary should get a pass. 

Concretely, that means: back tool-server credentials with whatever secret store your bank already runs (Vault or equivalent), not environment variables baked into a container image; use the MCP authorization flow — OAuth with PKCE, scoped narrowly per tool server rather than one shared client credential across every MCP server in your fleet — instead of static API keys; bind session identity to the actual authenticated user (user_id:session_id, validated on every request) so a session token can't be replayed against a different caller's context; and apply resource limits — rate limits, quotas, timeouts — per session, the same way you'd throttle any other client of a payments API. None of this is exotic. It's the standard OAuth-and-secrets-manager posture your team already runs elsewhere, applied to a new front door instead of invented from scratch for this one. 

The default-open trap is worth calling out explicitly, because it's the one every team hits once: Spring AI's own documentation states plainly that its HTTP-based transports expose an unauthenticated JSON-RPC endpoint by default, and that you must put a security boundary — Spring Security, or the community mcp-security project — in front of it before it's reachable beyond localhost. A tool server that works perfectly in local dev, behind no auth, is not a tool server that's ready to point at a payments service. That gap between "the demo works" and "this is safe to expose" is exactly where these projects lose weeks if it isn't planned for from the first sprint. 

The tool boundary needs the same guardrail discipline as any other AI-facing surface 

We've written before about why free text should never be the thing that moves money in an LLM-backed banking chatbot — the same principle applies at the tool server, just one layer earlier. A get_transaction_status tool is safe to let an agent call autonomously. An initiate_transfer tool is not, regardless of how well-scoped its OAuth token is — it needs an explicit human-approval step before execution, not just before the UI renders the result, and that approval has to be enforced by the tool server itself, not left to whatever the client application chooses to do with the response. Log every invocation — full parameters, caller identity, timestamp — into the same audit pipeline your other regulated systems already feed, for the same reason we've argued a DORA-grade audit trail needs to be independent of the system it's describing: "the agent called it and got a 200" is not an answer your risk function will accept for how a transfer happened, any more than "the model generated it and the tests passed" is an answer for how a line of production code came to exist. 

None of this is a reason to avoid building the tool server. It's the reason to build it deliberately: Streamable HTTP as the default transport, a curated tool registry instead of an annotated mirror of your service layer, caller-scoped credentials instead of one shared token, and a security boundary in front of the endpoint before anything beyond localhost can reach it. We've spent years putting Java backends in front of systems where a mistake shows up as a wire transfer, not a stack trace. An MCP tool server is a new kind of front door into that backend. It doesn't get to skip the discipline the rest of the door already has. 

Building a Production-Grade Tool Server for Banking Backends 

Spring AI makes exposing a tool server easy. Making it production-grade for a banking backend is different work. Here's the transport, tool registry, and secrets-handling patterns that close the gap.

Spring AI + MCP make a tool server easy. Production-grade for a banking backend needs real transport, registry, and secrets patterns.

Spring AI + MCP 

Most of the engineers staffed onto a COBOL modernisation project don't read COBOL — they read Java, and they've been handed an AI assistant and told it closes the gap. It closes some of it. This one's for the Java engineer holding the bridge, who needs to know exactly which parts of that gap an LLM actually closes, and which parts it will confidently paper over if nobody stops it. 

Anthropic's announcement that Claude Code can analyse and document COBOL codebases — mapping dependencies, flagging risk, translating logic into modern languages, modernisation in "quarters rather than years" instead of the usual multi-year programme — moved IBM's stock down over 13% in a single day. That reaction tells you something true: the market believes AI-assisted legacy modernisation is now real enough to threaten the economics of staying on the mainframe. It doesn't tell you whether the code an LLM writes on your core banking ledger is safe to ship, and those are two different questions. The demo that impresses a room is a self-contained COBOL program with clean copybooks. The core your bank actually runs is forty years of paragraphs, GOTOs, and copybooks written by people who left before you were hired, none of it designed to be read out of context. 

Reading isn't understanding, and the failure mode is invisible until it isn't 

What LLMs are genuinely good at against real COBOL is close to what they're good at against any unfamiliar codebase: tracing program flow, mapping which paragraphs call which, pulling a plausible-sounding business rule out of an undocumented subroutine, and turning that into fluent documentation a Java team can actually read. What they're weak at is the thing that matters most on a core banking system — resolving a data structure's true shape when the answer lives somewhere the model didn't look. 

Here's the shape of the failure, as described in accounts from teams doing exactly this kind of migration: an AI system translated a COBOL financial module to Java. It compiled. It passed the unit tests the same AI had written for it. In production, it corrupted a database on the first live wire transfer. The root cause was a field — call it TRN-LIMIT — defined thousands of lines earlier in a copybook, carrying a REDEFINES clause that let the same memory reinterpret as a different data type depending on a runtime condition. The model read TRN-LIMIT where it was used, in the transaction paragraph, and treated it as a plain numeric field, because that's what it looked like locally. It never resolved the REDEFINES chain back to its actual definition — not because it couldn't, but because a RAG-style retrieval step finds text that's semantically similar to what you asked about, and a REDEFINES clause buried in an unrelated copybook doesn't read as similar to a payment paragraph. It reads as unrelated, right up until it's the thing that decides how the bytes get interpreted. 

That's the failure mode worth designing prompting patterns around: not the model being wrong about something it looked at, but the model being confidently right about something it never looked at, because nothing forced it to look. A COBOL codebase's real structure — copybook inheritance, REDEFINES, OCCURS DEPENDING ON, 88-level condition names — isn't always where the paragraph you're translating happens to be. Treating it like a self-contained unit of text, which is exactly what a chat-style prompt or an IDE-scoped Copilot completion implicitly does, is where these projects go wrong. 

Prompting patterns that assume the model can't see what you haven't shown it 

The fix isn't a smarter model. It's context discipline that doesn't rely on the model finding what it needs on its own. 

Enumerate the copybook chain before you ask for a translation, and paste all of it in. Before asking Claude or Copilot to translate a paragraph, walk every COPY statement it depends on and every REDEFINES on every field it touches, and put the full text of that chain in context — not a summary, not "here's the copybook it probably needs." If a field is redefined three copybooks away from where it's used, that redefinition has to be physically present in the prompt, because retrieval won't reliably surface it and the model has no way to ask you for it. 

Ask for a data dictionary before you ask for code. Two-step prompting beats one-step here: first, have the model enumerate every field the paragraph touches — its PICTURE clause, its REDEFINES if any, its 88-level condition names — as a table, before it writes a single line of Java. Reviewing that table against the copybook is fast for a human who doesn't read COBOL fluently; reviewing generated Java line-by-line for the same errors is not. If the model's data dictionary is wrong, you've caught the TRN-LIMIT-shaped bug before it became a bridge. 

Generate characterization tests before translation, not from the translation. A model asked to translate a paragraph and then write tests for its own output will write tests that confirm what it believes the paragraph does — which is exactly the confidence that missed the REDEFINES clause in the first place. Instead, ask it to generate golden-master tests from the existing COBOL behavior against representative input data, run against the current system, before any Java exists. The Java bridge then has to match a behavior captured independently of the model's own understanding, not a test suite the model wrote to agree with itself. 

Never let a model choose between double and BigDecimal. COBOL's COMP-3 packed decimal fields carry an exact scale and precision from the PICTURE clause — that's the entire reason COBOL is still running the general ledger. A model translating that field to a Java double or float isn't simplifying, it's silently introducing floating-point rounding into money math. The prompting pattern here is a standing instruction, not a per-task one: every numeric field maps to BigDecimal with scale and rounding mode taken explicitly from the source PICTURE clause, and the model has to state the PICTURE clause it read for each field so a reviewer can check the mapping against the copybook rather than trusting the narrative. 

Flag control flow instead of "cleaning" it. A GOTO or PERFORM ... THRU that looks dead in isolation can be what sequences an overnight batch job. Ask the model explicitly to flag every GOTO, ALTER, and PERFORM ... THRU it encounters and explain what it thinks controls it, rather than quietly restructuring the paragraph into cleaner-looking Java — a model instructed to simplify will simplify, including the parts it didn't understand were load-bearing. 

Use the bridge, not the rewrite, as the default prompting target 

The safest place to point an LLM on a legacy core isn't "rewrite this business logic in Java." It's the adapter layer around it. Java-calling-COBOL over JNI is a well-documented, mechanical pattern — a native method declared with the Java_classname_methodname convention, two hidden JNI arguments the COBOL side receives from the runtime, the compiled COBOL loaded as a shared library via System.loadLibrary(). That's exactly the kind of boilerplate-heavy, well-specified integration code LLMs are reliable at, because it's mechanical translation against a documented interface, not an inference about what forty-year-old business logic was supposed to mean. 

Prompt pattern (bridge generation, not logic translation): 

"Generate a JNI adapter that calls COBOL program PYMT100 from 

Java. Native method signature: calculateSettlement(BigDecimal 

amount, String currencyCode) returning SettlementResult. Do not 

reimplement PYMT100's internal logic — the COBOL program remains 

the source of truth for the calculation. Map COMP-3 fields per 

the attached copybook PYMT100-COPY.cpy exactly as specified; 

flag any field where the copybook doesn't fully determine scale 

That's the strangler-fig pattern applied to prompting: Java owns orchestration, the COBOL program stays authoritative for the calculation it was already trusted with, and the AI-generated surface area is the boring, verifiable adapter code rather than a reimplementation of business logic nobody's fully documented. It also changes what "AI-assisted modernisation" means as a phased programme — you can ship the bridge and start decommissioning around it long before anyone reimplements the underlying paragraph in Java, and the highest-risk translation work only happens once, deliberately, with a subject-matter expert in the loop, instead of as an implicit side effect of every prompt. 

Copilot and Claude earn different roles in this split. Copilot's inline, IDE-scoped suggestions are well suited to the adapter and boilerplate layer — small, well-specified completions reviewed in place, paragraph by paragraph. Claude's larger context window and agentic tooling are better matched to the analysis phase — ingesting a full copybook chain, producing the dependency map and data dictionary, flagging the REDEFINES and the GOTOs before a human decides what's safe to touch. Neither belongs unsupervised in the paragraph that calculates interest. 

Traceability is the part that makes this auditable, not just accurate 

Everything above produces a review burden, and the review burden is the point — but it only works if it's checkable after the fact, not just at merge time. Annotate every AI-generated line with where it came from: a source comment referencing the exact COBOL program and line range it was translated from, not just a commit message. Log the prompt, the context that was actually supplied, and the output together, so that eighteen months later, when an auditor or a regulator asks how a specific line of Java came to exist, the answer is a record instead of a reconstruction. We've written before about what DORA's operational resilience testing actually expects of an audit trail — evidence independent of the system it's describing, not a belief about what probably happened. AI-assisted migration on a regulated core needs exactly that same discipline, because "the model generated it and the tests passed" is not an answer a regulator, or a bank's own risk function, will accept for how a payment calculation changed. 

None of this makes COBOL-to-Java migration fast in the way the headlines promise. It makes the parts of it that are genuinely mechanical fast — and it keeps the parts that aren't mechanical in front of a human who can read a copybook, instead of letting an LLM's fluency stand in for understanding it never actually had. On a core that moves real money, that trade is the whole point. 

Claude and Copilot on Legacy Cores  

Claude and Copilot can read COBOL. Reading isn't understanding — here are the prompting patterns that keep a COBOL/Java bridge safe to ship.

Prompting Patterns for COBOL/Java Bridges 

Ship a React Native banking app in one country and accessibility, localisation are two checklist items. Ship the same codebase into eight countries and they become a combinatorics problem: every screen, times every locale, times every screen reader, times every release. This one's for the React Native developer who owns that matrix and has stopped pretending a human can hold all of it in their head. 

A single-market app can get away with a manual accessibility pass before each release and a translator who reads the diff. A multi-country banking app on one React Native codebase can't — not because the team got lazier, but because the surface area grew multiplicatively while the review capacity stayed the same. Two hundred screens across a core banking app, six markets, VoiceOver and TalkBack, and a release cadence measured in weeks, not quarters, is not a QA checklist anymore. It's a coverage problem, and coverage problems are exactly where it makes sense to put an LLM to work — not to write the app, but to keep watch over what a human reviewer can no longer see all of. 

The deadline that already passed, and the one that's about to move 

The European Accessibility Act has applied to consumer banking services since 28 June 2025, and it doesn't grandfather existing apps — a banking app that launched in 2020 has to be fully accessible for any use after that date, the same as one shipped last month. There's no broad transition period for digital services; the narrow exceptions in the Act cover things like pre-existing B2B service contracts and legacy self-service terminals, not a mobile banking app your retail customers use today. If your app serves consumers in the EU, this isn't a future compliance project. It's already the legal baseline. 

What's about to change is which baseline. The harmonised standard behind the EAA, EN 301 549, is still on v3.2.1 and WCAG 2.1 AA as of today. Version 4, currently in draft, moves the reference standard to WCAG 2.2 AA and is expected to be cited in the EU Official Journal around October 2026 — a few weeks out from whenever this piece is read. Two of the six new WCAG 2.2 criteria land directly on banking UI: Target Size, which sets a minimum touch-target size that a lot of dense transaction-list and confirmation-button designs quietly violate, and Accessible Authentication, which prohibits login or step-up flows that rely on a cognitive function test — memorising or transcribing an OTP — without an alternative like copy-paste or a password manager. If your OTP screen currently expects someone to hold a six-digit code in their head while switching apps, that's the exact pattern the new criterion targets. 

None of that is enforced identically across markets, either. The EAA is a directive: the technical standard is harmonised, but each member state transposes it into national law with its own enforcement body and penalty regime — Germany's BFSG is one visible example. A multi-country app isn't meeting one accessibility bar; it's meeting one technical standard under several different national enforcement regimes at once, which is one more reason a manual, country-by-country audit doesn't scale as a review process. 

Where React Native's accessibility API actually breaks down at scale 

React Native gives you the primitives — accessibilityLabel, accessibilityRole, accessibilityHint, accessibilityState — and they work well when a developer remembers to use them correctly on every interactive element. The failure mode isn't ignorance of the API; open-source guides like Nearform's React Native AMA document the patterns clearly enough. The failure mode is that correctness is a per-component, per-PR discipline, and at 200+ screens across a team that rotates and ships weekly, discipline degrades quietly. A toggle ships without an accessibilityState update on press. An icon-only button ships with no label at all. A custom component wraps a Pressable and inherits none of the accessibility props the design system intended. Each one is a one-line fix. Finding them all, before release, across every screen and every locale, is the part that doesn't scale linearly with headcount. 

This is where an LLM earns its place in the pipeline — as a coverage layer over a PR diff, not as the thing writing the label. Wired into CI against the JSX AST of changed files, it can flag a TouchableOpacity with no accessibilityLabel, a custom toggle missing accessibilityState, or an image with an alt-equivalent that just repeats the filename — and propose a specific fix rather than a generic warning. Research on LLM-generated accessible UI code backs up what you'd expect from using these models directly: they're reliable on standard patterns like semantic roles and basic labels, and much weaker on custom components, dynamic content announcements, and focus management inside modals — one benchmark found only about a third of AI-generated sortable tables correctly announced state changes. The gap matters less for what it says about the model and more for what it implies about the workflow: treat the output as a flagged draft requiring review, never as a merge-ready fix, and the same research found that prompts anchored to a specific WCAG success criterion — "this needs an accessibilityState update per SC 4.1.2," not "make this accessible" — measurably improve what comes back. Deterministic tooling still does the enforcement; eslint-plugin-react-native-a11y catches the mechanical cases (missing labels on touchables, images without alt text) reliably and cheaply. The LLM's job is the harder-to-rule-ify layer on top: is this label actually descriptive, does this hint add real information, does this custom component's role match what it does. 

Localisation has the same shape, and the two problems compound each other 

A multi-country banking app's i18n surface isn't just translated strings — it's currency and date formatting per locale, pluralisation rules that don't map cleanly from English, interpolation placeholders that have to survive translation intact, and string length expansion that varies wildly by language. German banking terminology in particular runs 30–40% longer than the English source string, and that's not a cosmetic problem — a label that truncates on a small screen doesn't just look wrong, it silences the screen reader reading it or turns a clear call-to-action into an ellipsis. Localisation and accessibility bugs aren't two separate backlogs on a banking app; a truncated German label is both at once. 

The same coverage-layer approach applies. An LLM reviewing a locale-key diff can catch what a translation memory tool won't: a missing key that silently falls back to the source language in production, an interpolation placeholder ({{amount}}, {{accountLastFour}}) that survived in one locale file but got flattened into plain text in another, or a string that's technically translated but uses consumer-facing phrasing where the source string was written for a KYC or compliance screen and needed the formal register a given market's banking terminology expects. It can also flag, before a string ever reaches a device, which translated strings are likely to overflow a given layout given that locale's typical expansion ratio — catching the German-label problem in CI instead of in a screenshot review three sprints later. 

CI flag on PR #4127 (ro-RO, de-DE locale diff): 

de-DE: "transfer.confirm.button" translated but exceeds button's 

  maxLines(1) budget at 98th-percentile string length (+34% vs en-US 

  source). Suggest: shorten label or increase touch target per WCAG 

  2.2 SC 2.5.8 minimum size — current button clips to 38x38pt. 

ro-RO: "otp.hint" interpolates {{expirySeconds}} — key present in 

  en-US and de-DE, missing in ro-RO. Falls back to source string 

Both: flagged for native-speaker + a11y review before merge. 

What AI should never be the last reviewer of 

The guardrail matters as much as the capability. Interest rate disclosures, consent language, KYC copy, anything a national regulator would read as the actual legal text of the product — that copy gets written and reviewed by a native-speaking compliance reviewer in that market, full stop. What the LLM is good for is making sure that copy exists in every locale it needs to, that it hasn't silently regressed, and that the button it sits in doesn't clip it — not authoring the copy itself. The distinction is the same one that shows up anywhere AI touches a regulated pipeline: use it to raise coverage and catch drift, keep a human accountable for anything a regulator, a screen reader, or a customer in a market you don't personally read the language of would actually rely on. 

Testing like the market surveillance authority will 

EAA enforcement doesn't run against your English staging build. A national market surveillance authority testing a banking app for compliance will test the actual deployed app, in the actual local language, with the actual assistive technology customers in that country use — which means your own test matrix needs to mirror that, not substitute an English-only VoiceOver pass and call the rest "covered by translation." A coverage matrix generated per screen, per locale, and per platform — and kept honest by the same CI layer that flags missing labels and overflowing strings — is what makes "we tested it" mean the same thing in Bucharest and Berlin, instead of meaning "we tested the English version and hoped." 

We've built and shipped React Native banking apps that run across multiple markets on one codebase, and the lesson that stuck is a boring one: neither accessibility nor localisation breaks because a team doesn't care. It breaks because a per-PR discipline doesn't scale to a multi-country release matrix, and nobody notices the gap until either a regulator or a customer does. An LLM in that pipeline isn't a replacement for an accessibility specialist or a native-speaking reviewer — it's the coverage net that makes sure the specialist's judgment gets applied to every screen, in every market, every single release, instead of whichever ones a human had time to click through before the deadline. 

Accessibility and Localisation at Scale for Multi-Country Banking Apps 

Accessibility and localisation don't scale linearly across a multi-country React Native banking app. Here's how AI can generate and validate a11y and i18n coverage before a regulator — or a customer — finds the gap.

AI can generate and validate a11y and i18n coverage across multi-country React Native banking apps — before a regulator or customer finds the gap.

React Native + LLMs 

Ask most frontend teams where LLM guardrails live and you'll get the same answer: the backend. Prompt engineering, retrieval pipelines, output classifiers, tool-call permissions — all backend concerns, all somebody else's problem. That's true right up until the moment a hallucinated fee amount renders in a chat bubble with the same visual authority as a verified balance, or a cleverly worded paste triggers an action nobody asked for. At that point it's not a backend incident. It's whatever the customer saw on their screen, and the screen was built by the frontend team. 

The 2026 revision of the OWASP LLM Top 10 reframes the whole problem usefully: stop trying to make the model perfect, and instead build the system around it so that when it fails — and it will — nothing important breaks. That's a containment argument, and containment doesn't stop at the API boundary. For a banking chatbot, the UI is the last layer standing between a model's mistake and a customer's money or trust. It deserves to be treated as a guardrail layer in its own right, not just a rendering target for whatever the backend decided to send. 

The response you render is untrusted input, not a trusted answer 

It's easy to treat an LLM's output as first-party content, because it comes from your own backend, over your own API, wrapped in your own response schema. Treat it that way and you inherit whatever the model produces, including content an attacker steered it into producing. OWASP's 2026 list still ranks improper output handling as a live risk category precisely because teams keep making this mistake: rendering model output as if it were safe just because it arrived through a trusted pipe. 

In practice, that means the chat UI needs the same discipline you'd apply to any user-generated content, applied to every model response: 

Render responses through a constrained markdown renderer with an explicit tag allowlist — no raw HTML, no dangerouslySetInnerHTML-equivalent without sanitization (DOMPurify or an equivalent), no inline styles or event handlers surviving the render pass. 

Treat links in model output as suggestions, not destinations. A prompt-injected model can be steered into recommending a link that looks like your own domain. Resolve links server-side against an allowlist before the client ever makes them clickable, rather than trusting whatever markdown the model emitted. 

Apply a strict Content-Security-Policy as a second layer, not a substitute for sanitization — CSP catches what sanitization missed, it shouldn't be the only thing standing between a malformed response and script execution. 

None of this is exotic frontend security. It's the same discipline you'd apply to any untrusted content pipeline. The only thing that changed is the source now writes fluent, plausible-looking prose instead of obviously malformed input, which makes it easier to forget the discipline applies at all. 

The context you assemble is part of the attack surface, not just what the user typed 

Prompt injection doesn't only arrive as a message the user types directly. Once your chatbot pulls in pasted text, uploaded statements, or retrieved account content as part of the payload sent to the model, every one of those becomes a channel an attacker can use — and a lot of that assembly happens client-side, in the same code that builds the request. 

A customer pasting a "helpful" snippet from a phishing email, a scanned statement with injected text in a hidden layer, or a support macro copied from a forum post can all carry instructions the model will treat as part of its context unless something marks them as untrusted before they leave the browser. A few defenses belong here, not in the backend: 

Delimit and tag anything the client assembles from user-supplied or fetched content — wrap it clearly as data, not instruction, before it's added to the outgoing payload, so the backend's prompt structure can treat it accordingly. 

Normalize input before it's sent: strip zero-width characters, bidirectional-override marks, and other invisible-unicode tricks that are a known way to hide injected instructions inside otherwise unremarkable pasted text. 

Flag large pastes or file uploads to the user before they're sent — not as a security theater warning, but because it's a real moment to catch "wait, I didn't mean to paste that whole email thread" before it becomes model context. 

The backend can and should defend against injection too. But it can only defend against what actually reaches it in a recognizable form — the client is the only layer that sees the content in its original shape, before assembly, and it's the only layer that can flag it before it's flattened into an opaque prompt. 

Free text should never be the thing that moves money 

Excessive agency — a model taking an action beyond what was actually warranted — climbed to the #3 risk in the 2026 OWASP list, and for a banking chatbot it's the single most consequential failure mode. The backend should absolutely scope what any tool call is allowed to do. But the UI has its own version of that responsibility: never let a model's free-text output directly trigger a transfer, a limit change, or a card action. The model should propose a structured, schema-validated action object, and the UI should render that proposal as an explicit confirmation the customer has to approve — not infer intent from prose and act on it. 

Model output (rejected by the client if malformed): 

  "recipient_account": "RO49AAAA1B31007593840000", 

- Validate against the action schema before rendering anything. 

- Render a confirmation card with the parsed fields, not the model's 

- Route to step-up authentication (SCA) before submission if the 

  schema flags it — the model doesn't get to decide this is skippable. 

This does double duty. It's a hard technical guardrail against a hallucinated or injected action executing silently, and it's a UX moment where a hallucinated amount or wrong recipient becomes visible to the one person positioned to catch it before it becomes a real transaction — the customer looking at the confirmation card. 

Make groundedness visible, not just true 

A well-built retrieval pipeline reduces hallucination on the backend. It doesn't help the customer if the UI presents every sentence the model produces with identical visual authority, whether it's a fact pulled straight from a fee schedule or a plausible-sounding number the model generated to fill a gap. If the backend can tag which claims are grounded in a retrieved source and which aren't, the frontend is where that distinction actually reaches the person who needs it. 

Concretely: render source-grounded claims with a visible citation — a reference chip linking to the actual policy document or account record it came from — and treat ungrounded statements differently, whether that's softer visual styling, an explicit "verify with an advisor" affordance, or declining to render a specific number at all if it isn't traceable to a source. A customer can't apply judgment to a hallucination that looks identical to a verified fact. Giving them that visual distinction is a guardrail as much as a UX nicety. 

Telling the customer they're talking to AI stopped being optional two weeks ago 

Article 50 of the EU AI Act — the transparency obligation requiring that users be informed they're interacting with an AI system, "at the latest at the time of the first interaction," unless it's already obvious — took effect on 2 August 2026. For a banking chatbot, this isn't a checkbox you can satisfy with a line in the terms of service. It has to be clear and distinguishable at the point of interaction, which puts it squarely in frontend scope: a persistent, accessible label on the chat interface, not a disclaimer a customer has to go looking for. It's also a reasonable moment to reinforce the same message the rest of this piece is about — the customer should understand they're talking to a system that can be wrong, at the exact point they're deciding whether to trust what it just told them. 

We've written before about what DORA's threat-led penetration testing actually demands of an architecture — live-production testing, no advance notice to the team being tested. A conversational banking UI is exactly the kind of surface that testing will probe, and it's worth holding the frontend to that standard before an external red team does it for you. Render fuzzing with malformed markdown, injected script tags, and unicode obfuscation tricks belongs in the same test suite as your component snapshots. The confirmation-card flow deserves adversarial test cases specifically designed to check that a malformed or partially-valid action object gets rejected rather than rendered with best-effort guessing. If your QA process trusts the model to always produce well-formed output, you've already found the gap an attacker will. 

None of this replaces backend-side guardrails — retrieval grounding, output classifiers, tool-call scoping all still matter, and matter first. But the frontend is where a model's failure becomes a customer's experience, and increasingly, where regulation expects that failure to be visibly and honestly presented rather than smoothed over. Building banking software has always meant treating the interface as part of the control environment, not just the presentation layer on top of it. LLMs haven't changed that. They've just given the interface a new kind of failure to contain. 

Guardrails in the UI Layer 

Guardrails for LLM banking chatbots don't stop at the backend. Here's the frontend's role in containing hallucination, prompt injection, and excessive agency before they reach the customer.

Guardrails for LLM banking chatbots; frontend's role in containing hallucination, prompt injection, and excessive agency before they reach the customer.

Client-Side Defenses for LLM-Backed Banking Chatbots 

I used to write requirements the way most BAs do: prose paragraphs, a table of acceptance criteria, and a quiet trust that whoever picked up the ticket would fill the gaps sensibly. That trust was well placed with a developer — they'd ask in standup, ping me on Slack, or just apply the same domain judgment I'd apply if I were coding it myself. An AI agent doesn't do that. It reads what's on the page, makes a confident decision about everything that isn't, and ships it. That single difference is rewriting what a good spec looks like. 

Requirements haven't changed. What's changed is who — or what — reads them first. When a developer picked up a ticket, the spec was a starting point for a conversation. When an agent picks up the same ticket, the spec is the conversation, and whatever it doesn't say gets decided by a model with no stake in getting it right and no instinct to ask. For a BA, that's not a tooling change. It's a change to the actual skill. 

The gap a developer used to fill silently, an agent fills with a guess 

Every requirements doc has gaps — not from carelessness, but because some things are genuinely easier to say in a hallway than in a ticket, and because a competent developer fills them in automatically from context you both share. "Handle the error case sensibly." "Match the existing pattern." "Obviously this should be idempotent." A developer reads those and reaches for the same domain knowledge you have. An agent reads them and reaches for whatever's statistically plausible, which is not the same thing, and it won't flag the difference before shipping it. 

This is the part that catches BAs off guard the first time: the failure mode isn't the agent refusing to proceed on an ambiguous requirement. It's the agent proceeding confidently, producing something that compiles, passes the tests it wrote for itself, and does the wrong thing — because the wrong thing was a perfectly reasonable reading of an underspecified sentence. A human reviewer used to be your safety net for that kind of gap. With agent-generated code shipping faster and in higher volume, you can't rely on review to catch every one of them. The spec has to close the gap before the agent gets there. 

From prose requirements to acceptance criteria that map to tests 

The most direct fix is also the most mechanical one: write acceptance criteria in a constrained syntax that maps one-to-one onto a test case, instead of a sentence that admits more than one reading. EARS (Easy Approach to Requirements Syntax) has become the practical standard for this, precisely because it's restrictive enough to force the ambiguity out during writing rather than during code review. Five patterns cover almost everything a BA needs: 

Ubiquitous:        The system shall [always-true behavior]. 

Event-driven:       When [trigger occurs], the system shall [response]. 

State-driven:        While [condition holds], the system shall [behavior]. 

Unwanted behavior:  If [error condition], then the system shall [consequence]. 

Optional feature:   Where [feature is enabled], the system shall [behavior]. 

Compare the two versions of the same requirement: 

Prose version: "The system should stop customers going over their daily transfer limit." 

When a customer initiates a transfer that would cause their cumulative 

daily transfer total to exceed their configured daily limit, the system 

shall reject the transfer and return error code TRANSFER_LIMIT_EXCEEDED. 

If the customer's daily limit has not been configured, then the system 

shall apply the account-tier default limit before evaluating the 

While a transfer is pending manual review, the system shall exclude 

its amount from the cumulative daily total until the review resolves. 

The prose version reads fine to a person and hides three decisions: what happens at exactly the limit, what happens when no limit is configured, and how pending transfers count toward the total. An agent will resolve all three — just not necessarily the way you would have. The EARS version forces you, the BA, to make those calls at spec time, which is where they're cheap, instead of discovering them in QA or production, where they aren't. 

Scope has to be written as a boundary, not implied by omission 

Developers generally under-build relative to a vague spec — when in doubt, they ask rather than add. Agents skew the other way. An agent optimizing for "complete, working code" will often add validation, retry logic, extra endpoints, or configuration options you never asked for, because it read the ticket as a starting point for a plausible feature rather than a bounded unit of work. That's scope creep with no human in the loop to notice it's happening until the PR is already large. 

The fix is a section most human-facing specs skip entirely: explicit out of scope. Not "we'll figure that out later," but a direct list of what the agent should not touch, build, or infer — adjacent endpoints, related tables, configuration surfaces, anything that looks like natural extension work but wasn't asked for. It reads like unnecessary caution when you're writing it for a person. It's load-bearing when you're writing it for an agent that has no sense of "not my job." 

Edge cases can't live in the tester's head anymore 

QA has always caught things the spec didn't spell out, because a human tester brings the same tacit domain sense a developer does — they poke at boundary conditions, weird input, and unlikely sequences because experience tells them that's where bugs live. An agent implementing from a spec doesn't have that instinct working in your favor. It builds to what's written. If the null case, the zero case, the "customer closes the account mid-transaction" case aren't in the spec, there is no guarantee of a human catching that gap before it ships — and increasingly, no guarantee a human is even in that part of the loop. 

That means edge cases move from "things QA will probably find" to "things the BA has to enumerate," and enumerate specifically enough that each one reads as its own EARS statement rather than a bullet under "edge cases to consider." It's more writing up front. It's also precisely the kind of writing a BA is already trained to do — thinking through what happens at every boundary of a business rule — just aimed at a reader that won't do that thinking on your behalf. 

Traceability isn't a nice-to-have anymore — it's the acceptance test 

The teams getting real value from agent-driven delivery aren't the ones handing an agent a spec once and letting the code drift from it afterward (what the field's calling spec-first), and they're not going all the way to letting specs alone govern every change with no human anchor (spec-as-source — still mostly hype). The sweet spot in practice is spec-anchored: the spec and the code evolve together, and every acceptance criterion has a test that fails the moment the code drifts from what was specified. That only works if every requirement, acceptance criterion, and generated test can be traced back to each other — which is a BA deliverable, not an engineering afterthought. 

For anyone delivering into a regulated environment, this should sound familiar rather than novel: it's the same traceability discipline auditors already expect between a requirement and the evidence it was met. Agent-executed specs just make that discipline mandatory for the software to work correctly, not only to pass an audit. A spec that traces cleanly is one where an agent's output can be checked against intent automatically — and one where, six months later, someone can still answer "why does the system behave this way" by pointing at a document instead of reverse-engineering the code. 

In practice, this is showing up as a structured workflow rather than a single document: a short constitution of non-negotiable rules for the domain, a specification of the feature in EARS-style acceptance criteria, a clarification pass where ambiguities get resolved before any code is written, a plan the agent proposes against that spec, and a task breakdown that cites the specific requirement each piece of work traces back to. Tooling is converging around this shape — GitHub's Spec Kit, Claude Code's spec-driven workflows, Cursor's plan mode, and several others all implement some version of specify-clarify-plan-implement — but the pattern matters more than any specific tool, and it's a workflow a BA is better positioned to own than anyone else on the team. 

None of this replaces the judgment a good BA already brings — understanding the business, negotiating trade-offs with stakeholders, knowing which ambiguity is safe to leave and which isn't. What's changed is that the artifact carrying that judgment now has to survive being read by something with none of its own. Writing it that precisely used to be optional, a nice-to-have for the BAs who liked structure. Now it's the difference between an agent building what the business actually needs and an agent building a confident, well-tested guess. 

We've built delivery practices around exactly this kind of precision for banking clients long before agents were part of the toolchain — audit trails, traceable requirements, and specs written to survive scrutiny from someone who wasn't in the room. That discipline turns out to be the same discipline agent-driven delivery now demands. It's just got a new reader. 

Writing Specs an Agent Can Execute  

Acceptance criteria need to change when an AI agent, not a developer, is the one building from your spec. 

The New BA Skillset 

Most DORA compliance content is written for risk and legal teams, and reads that way — obligations, deadlines, templates. That's fine for the register of information. It's not much use when you're the engineer who has to make a live production system survive a red team, or make a vendor integration exit-able on paper actually be exit-able in code. This one's for that engineer. 

DORA has been in force since January 2025, but two of its provisions land differently than the rest of the regulation: threat-led penetration testing (TLPT) under Article 26, and ICT third-party risk management under Articles 28–30. Most of DORA is a documentation and governance exercise — policies, registers, board reporting. TLPT and third-party risk are not. They test whether your system actually behaves the way your documentation says it does, under conditions you don't control the timing of. That's an architecture problem before it's a compliance problem, and it's worth working through what these provisions actually require of the systems you build, not just the paperwork around them. 

TLPT tests your architecture, not your checklist 

TLPT, built on the TIBER-EU methodology, applies to designated entities — G-SIIs and O-SIIs, large payment institutions, major trading venues, and others your national competent authority selects — on a minimum three-year cycle. The mechanics matter more than the schedule: a threat intelligence provider profiles realistic attackers for your specific risk profile, then an accredited red team executes a covert attack against your live production systems, not a staging environment carved out for the occasion. Your SOC doesn't know it's happening. If they notice and respond, that's the point being measured. If they don't, that's also the point being measured. 

That last detail is the one worth sitting with as an architect. A test environment tells you whether your code passes a spec. A live-production, undisclosed red team engagement tells you whether your actual blast-radius containment, actual detection pipeline, and actual incident response hold up when nobody's expecting them to be tested. You can't retrofit that confidence in the eight weeks between scoping and test execution. It has to already be built in. 

A few patterns fall directly out of this: 

Bounded contexts that match your critical-function map, not your team structure. DORA requires you to classify business services as critical or important and scope TLPT around them. If your "critical function" spans a monolith that also holds unrelated batch jobs and internal tooling, your test scope — and your actual blast radius during a real incident — is the whole system by default. Domain boundaries that map to the regulatory classification of the function they support aren't just cleaner design; they're what lets you draw an honest, defensible scope line and contain a compromise to the side of it where it happened. 

Circuit breakers and bulkheads you can prove work, not just ones you've implemented. Resilience4j, service-mesh-level circuit breaking, connection pool isolation per downstream — these are common enough in banking backends. The gap is usually that nobody has verified they trip correctly under an adversarial load pattern rather than a well-behaved failure. Chaos engineering practice (fault injection in pre-production, ideally extended into shadow production traffic) is the closest thing to a dress rehearsal for what TLPT will actually probe. 

Abort criteria that are technically real, not just written in the rules of engagement. The TIBER-EU rules of engagement define conditions under which a test must stop — discovery of an unrelated live incident, system instability, a genuine zero-day. Whether that abort is executable in under a minute depends on whether you can actually revoke a credential, drop a connection pool, or isolate a service at the mesh layer on demand, rather than through a change ticket. mTLS with short-lived certificates, centralized token revocation, and network segmentation that doesn't depend on a human editing a firewall rule are what make "we can abort" true rather than aspirational. 

Detection has to be provable, and provable to a party that isn't you 

The purple-team phase at the end of a TLPT engagement compares what the red team actually did against what your SOC actually saw. This is where architecture and observability meet compliance directly: if your logging, tracing, and SIEM correlation don't produce an evidentiary trail independent of the systems under test, you can't demonstrate detection even when detection happened. 

In practice this means structured logging and distributed tracing (OpenTelemetry is the sane default in a Java stack now) that survive the compromise of any single service — logs shipped to storage the attacker's foothold can't reach or rewrite, correlation IDs that thread through service calls and through third-party API calls, and a SIEM pipeline that's genuinely decoupled from the production plane it's watching. An immutable, append-only audit trail — event-sourced through Kafka into WORM-compliant object storage is a common pattern — isn't just good practice; it's what turns "we believe we detected this" into "here is the timestamped record." 

The third-party boundary has to be a real boundary, not just a contractual one 

Article 30 requires a set of mandatory contract clauses for any vendor supporting a critical or important function: audit rights, defined SLAs, incident notification obligations, sub-outsourcing approval, and — the one with the most architectural weight — exit strategies built around a "mandatory adequate transition period." The text deliberately doesn't pin that period to a fixed number of months; what counts as adequate is judged against the complexity of the service, which means the burden of proof shifts to you to show the transition is actually executable in whatever time you've committed to. The Register of Information under Article 28 then requires you to map every one of those contracts to the ICT assets and business functions they support, kept current within thirty days of any change. 

None of that is enforceable by a legal clause alone if your codebase has quietly built the vendor's data model, API shape, and failure modes into your domain layer. The pattern that actually makes an exit clause executable is the one Java developers already know: ports and adapters. A well-defined internal interface for "core banking ledger," "payment rail," or "KYC provider," with the vendor-specific implementation living entirely behind it, is what makes a Register-of-Information exit strategy something you could actually run rather than something you'd have to write from scratch under regulatory pressure. It also means your canonical data model isn't the vendor's schema, which matters directly for the data-portability and secure-deletion obligations in the same article. 

Two more implications worth building for deliberately: 

Contract testing at the integration boundary. Tools like Pact let you pin the behavioral contract between your service and a third-party API independently of whether that provider's staging environment is available or representative. This matters more than usual under DORA because your due diligence and ongoing monitoring obligations require you to know when a provider's actual behavior drifts from what you contracted for — not just when it errors. 

Incident correlation that closes the loop with the provider, not just with your own systems. DORA's incident reporting timelines don't pause because the root cause was in a vendor's infrastructure. A webhook or API feed from critical providers into your own incident management pipeline, with SLA timers that start from provider notification, is what keeps your regulatory reporting clock accurate instead of dependent on someone manually checking a status page. 

Concentration risk is a dependency graph, not a spreadsheet 

Nineteen providers — cloud hyperscalers, core banking platforms, and market infrastructure among them — were designated as Critical ICT Third-Party Providers (CTPPs) in November 2025, putting them under direct EBA/ESMA/EIOPA oversight. If any of them sit underneath more than one of your critical functions, or underneath a sub-processor your other vendors also depend on, that's exactly the concentration risk DORA requires you to assess annually. 

The honest way to answer that question is to generate it from infrastructure, not to maintain it by memory. A live service-dependency graph — built from API gateway telemetry, infrastructure-as-code manifests, and service mesh configuration rather than reconstructed manually for an annual filing — will surface a shared sub-processor or a single-region dependency long before an audit does. For functions sitting on a CTPP-designated provider, that same graph is what tells you honestly whether you have a tested failover path to a second provider or region, or whether your resilience plan for that dependency is still theoretical. 

None of this is exotic. Bounded contexts, circuit breakers, ports and adapters, contract testing, immutable audit logs, dependency graphs generated from real infrastructure — these are patterns most senior backend engineers already reach for. What DORA changes is the cost of skipping them. A missing bulkhead used to show up as an incident postmortem; now it shows up as an unscoped TLPT finding with a named remediation owner and a board-level report attached. A tightly coupled vendor integration used to be a refactoring backlog item; now it's an exit strategy you have to prove works, on a filing deadline. 

That's the shift worth internalizing: DORA doesn't introduce new architectural principles so much as it removes the option of treating them as optional. We've built payment and core banking systems inside exactly these constraints for long enough to know where the gap between a documented control and an executable one usually shows up — and it's rarely where the compliance checklist is looking. 

Designing for DORA 

DORA's TLPT and third-party risk rules aren't just a compliance exercise — they test your architecture directly. Here's what they actually require you to build. 

DORA's TLPT and third-party risk rules aren't just a compliance exercise — they test your architecture directly

What Operational Resilience Testing Actually Requires of Your Architecture 

The GENIUS Act didn't just legalize payment stablecoins in the United States — it put a compliance clock on every bank's balance sheet. With a federal framework deadline of January 2027, a market Treasury Secretary Scott Bessent has projected could reach $3.7 trillion by 2030 (up from roughly $250 billion today), and McKinsey estimating tokenized deposit flows already exceeding $4 trillion annually, stablecoins have moved from a speculative product line to an infrastructure decision with a hard deadline attached. For COOs and Heads of Payments, the question is no longer whether to engage. It's whether the plumbing underneath treasury operations can actually support what's being asked of it. 

Why This Landed on Treasury's Desk, Not Just Compliance 

The instinct in many banks has been to route stablecoin strategy through legal and compliance, treating it as a licensing and AML question. That undersells the exposure. S&P Global Ratings has flagged a structural vulnerability in how value moves once it leaves the bank: for every $1,000 a customer converts into a third-party stablecoin, only about 15% typically returns to the banking system as reserves, compared with 100% retention when a bank issues its own tokenized deposit. At scale, that's a direct threat to deposit funding stability, payment income, and lending capacity — which is why this is a balance sheet problem before it is a technology problem. 

Banks are responding accordingly. In June 2026, a consortium of major banks launched a tokenized deposit platform through The Clearing House, built for 24/7, interoperable movement of cash and securities. JPMorgan's Kinexys platform is already processing more than $1 trillion in tokenized transfers annually. US Bancorp is piloting stablecoin settlement on Stellar. Smaller institutions, like the Bank of North Dakota with its own tokenized instrument, are testing the same infrastructure at a different scale. Whatever the strategic path — issue a proprietary stablecoin, partner with an existing issuer, or hold the line with tokenized deposits — the decision gets made in the boardroom and executed in the infrastructure layer. That's where treasury and IT have to be in the same room. 

The Core Mismatch: Programmable Settlement Meets Batch-Era Operations 

Stablecoins and tokenized deposits settle continuously — 24 hours a day, with on-chain finality measured in seconds. Core banking systems, intraday liquidity models, and correspondent banking relationships were built around a different assumption: defined cutoff times, overnight batch processing, and end-of-day reconciliation. Cross-border payments make the gap concrete — more than 60% of wholesale cross-border payments still route through one or more correspondent intermediaries, a network that has shrunk roughly 30% over the past decade even as the volume it carries has grown. Stablecoin settlement promises to collapse that chain into a near-instant transfer. But collapsing it exposes every place where a bank's internal systems still assume the old rhythm. 

This is where the real operational risk sits — not in the underlying blockchain technology, which is now reasonably mature, but in the seams between it and infrastructure that was never designed to reconcile in real time, monitor exposure continuously, or hold a position open outside business hours. Treasury teams evaluating a stablecoin or tokenized deposit initiative need to press IT on exactly where those seams are before committing to a rollout timeline. 

The Questions Treasury Should Be Putting to IT 

These aren't procurement questions. They're the operational and risk questions that determine whether a stablecoin or tokenized deposit initiative is resilient under stress, or a source of reconciliation breaks and liquidity surprises six months after launch. 

Who holds the reserve assets backing any stablecoin or tokenized instrument we issue or accept, and how is that custody arrangement verified independently of the issuer? What is the contractual redemption SLA, and does our liquidity management system get real-time visibility into pending redemption requests — or only after settlement has already completed? 

Settlement and reconciliation architecture 

How does on-chain settlement finality map to our core ledger's definition of "settled"? Do we reconcile continuously against on-chain state, or in batch — and if it's batch, what is our exposure in the window between cycles? What is the exception-handling process when an on-chain transaction finalizes but the corresponding internal ledger entry fails to post? 

Stablecoins and Bank Balance Sheets 

GENIUS Act deadlines are pushing stablecoin settlement onto bank balance sheets. Here are the technical questions treasury teams should ask IT before rolling out.

GENIUS Act deadlines are pushing stablecoin settlement onto bank balance sheets; technical questions treasury teams should ask IT before rolling out.

All News

Categories

All News

Categories

Do you want to read more?

Subscribe now for our bimonthly newsletter!