How Banks Can Use AI and Keep Customer Data In-Region

Why does data residency matter for banks using AI?

Because the bank stays accountable for customer information even when an AI vendor or cloud provider handles part of the work. A regional storage setting is only one control. The bank has to know where data is processed, who can reach it, and which party owns each safeguard, a responsibility the FFIEC's statement on cloud computing makes clear.¹ It is also what bankers worry about most: in a 2026 survey of 17 community banks, 55% of respondents named security and data leakage as their top AI challenge.²

Picture a banker summarizing a customer file. The file may stay in the bank's cloud account while an excerpt travels to a model, an answer comes back, and a log is saved. Each step can have its own location and retention settings. Microsoft's documentation, for example, keeps stored data in the chosen geography, while prompts sent to a "Global" deployment may be processed in any Azure region.³ "Stored in-region" does not prove the whole workflow stays there.

So define the boundary first: one cloud region, one country, or a wider geography. Then trace source records, prompts, outputs, logs, backups, failover, support access and subcontractors. If one step crosses the boundary, a regional label can't settle the question. Recheck the map whenever a provider changes its model, routing, logging or failover setup.

What are the main deployment options?

There are three practical routes: a vendor-operated service with a regional commitment, an AI application in the bank's own cloud environment, or infrastructure on premises. The real question is who controls each part of the data path and who maintains it.

"Private cloud" doesn't necessarily mean on premises. NIST's definition allows a private cloud to sit on or off premises and to be run by the organization, a third party, or both.⁴ Ask where each workload actually runs and who owns the controls; the label isn't an answer.

What should a bank be ready to show examiners and auditors?

A decision trail: what the AI does, how customer data moves, who owns the controls, and how those controls are tested over time. Interagency guidance on third-party relationships calls for oversight scaled to the activity and its risk, including "ongoing monitoring throughout the duration of a third-party relationship."⁵ This is a practical evidence list, not an examiner script.

1. Purpose and risk: the task, the customer data it uses, and what happens if the AI is wrong or unavailable.
2. Data path: where records, prompts, outputs, logs and backups are stored and processed, including failover, subcontractors and any geographic terms in the contract.
3. Access and ownership: who can see data or change settings, including provider staff, and which controls the bank operates itself.
4. Evidence: due diligence, relevant audit reports, tests and monitoring records. Confirm each audit report covers the service and controls the bank relies on.
5. Incidents and exit: how the bank detects problems, restores service, and retrieves or deletes its data if it changes providers.

A data-flow diagram, the vendor's terms and day-to-day operating evidence should all support the same conclusion.

Where should a bank start with an AI pilot?

Start where no customer data is at risk. Point the AI at the bank's internal policies first. Once you've confirmed data stays in-region, move to one approved task where the AI reads customer documents but can't change them, with staff reviewing every output.

Why stage it? The revised model risk guidance from the Federal Reserve, OCC and FDIC, SR 26-2 (April 17, 2026, replacing SR 11-7), leaves generative and agentic AI out of scope and says a bank's own risk management and governance should set the controls for those tools.⁶ For the models it does cover, it warns that "using a model beyond its intended purpose introduces additional uncertainty and risk." That principle is worth borrowing: each expansion, whether a new document type, a new team or write access, gets its own review.

How does a bank scale AI without losing track of customer data?

Write the data boundary down once, then add one workflow at a time inside it. Score each workflow on two things: how accurate its outputs are, and whether the controls held. Expand only after the people who approved the pilot have reviewed that evidence.

Put the boundary on one page. Which regions data may sit in. Which systems the AI can read from, and which it can never write to. Which kinds of data are allowed. Who can see prompts and logs, and how long logs are kept. Anything a new idea needs that the page doesn't allow goes back to risk and compliance before anyone builds it.

Add workflows in order of data sensitivity. A sensible order for most banks:

1. Internal knowledge: policy and procedure search, with no customer data.
2. Read-only customer documents: checking files for missing items or summarizing them for a reviewer.
3. Drafting for staff: a first draft of a credit memo or exception report that an analyst edits and signs.
4. Anything that writes to a system of record: last, and always with a person approving each change.

Keep two scorecards from day one. A workflow can be accurate and still fail review because nobody can prove where its data went. Agree on the pass mark with your risk team before the pilot starts, not after you've seen the results.

Expand only after the review signs off. The gate to the next workflow is a meeting with a packet: the boundary page, both scorecards, and anything that went wrong and how it was fixed. If the packet is thin, the answer is not yet. The same interagency guidance is clear that using a third party "does not diminish" the bank's own responsibility.⁵ For a shared vocabulary, NIST's voluntary AI Risk Management Framework, released in January 2023 and now being revised, groups this work into four functions: govern, map, measure and manage.⁷

How does Soren help a bank scale this way?

Soren AI's engineers embed with your team, so the people who built the pilot are the ones who put together the review packet and answer your risk team's questions. We build into the systems you already run, like Fiserv or Jack Henry cores and nCino, instead of moving your data somewhere new, which keeps the boundary page short. We've shipped cloud, on-premises and hybrid deployments.

We also stay after launch, so the quarterly re-checks aren't handed to someone who has never seen the workflow. Your staff approve every output and make every decision; we make sure there's evidence that they did. More on the model in how we work, and on our work with banks and credit unions.