The AI Gateway for banks

1. 1. AI on your customers' data — without exposing it.

   This is the NeodyAI AI Gateway, built for banks. It sits on every path between your AI agents, the language models they use, and your systems, so agents can work with customer data without that data ever reaching the model.

2. 2. Two sides of every AI agent

   An AI agent combines two things. A language model, usually run by a third party, that reasons about the work. And your systems, where the work happens. The model doesn't need your customers' real account or card numbers to reason. Your systems can't act without them. And every model that influences a decision has to be inventoried, validated and controlled.

3. 3. Tokens to the model. Real values to your systems.

   Before anything goes to a model, the gateway finds protected values, like card data, account numbers and personal information, and replaces them with tokens. When the model asks for an action, the gateway restores the real values and passes them only to your approved systems, with the permissions of the person the agent works for. Results are tokenized on the way back.

4. 4. Tokens the model can work with

   The tokens keep their shape. A tokenized card number still looks and validates like a card number, so the model can reason about it. Within a conversation, the same customer always gets the same token. Outside the gateway, tokens can't be reversed.

5. 5. Finding protected data, inside your boundary

   Detection is pluggable, and the most certain methods run first: your own field definitions, validated patterns like card and routing numbers, and your known records. You can plug in the DLP and tokenization products you already run. When detection is uncertain, the value is protected. And no service outside your trust boundary ever receives your protected data.

6. 6. Keys per agent, per conversation

   Every agent has its own identity and keys. Every conversation gets its own session keys, and each call between an agent and the gateway is encrypted on top of TLS. You can rotate or revoke keys, and revoking ends sessions immediately.

7. 7. Model risk management, enforced on every call

   Because every model call passes through it, the gateway enforces model risk management, as SR 11-7 expects. Only approved models can be reached. New agents run alongside your people before they act. Approval comes from someone independent. When a vendor changes a model, agents relying on it lose autonomy until re-validated. And every call leaves a tamper-evident record for your examiners.

8. 8. What we claim, and what we don't

   We're precise about what we claim. Protected data is tokenized before it reaches any model, and the model provider never receives your protected values. We don't claim end-to-end encryption, because the gateway restores real values so your systems can act. And we measure and report detection rates rather than promising perfection.

9. 9. Start with a briefing

   You can run it in NeodyAI's cloud, isolated for your bank, or keep protection on your own premises for card data and the most sensitive information. It's being delivered in phases, so talk to us about availability for your bank, and ask for the detailed architecture briefing under NDA.

Questions

Does the AI model ever see our customers' card or account numbers?

Before anything is sent to a language model, the gateway finds protected values — card data, health information, personal information, account numbers, confidential business information, credentials — and replaces them with tokens. When the model asks for an action, the gateway restores the real values and passes them only to approved systems, acting with the permissions of the person the agent works for. A tokenized card number still looks and validates like a card number, so the model can reason about it and existing validation still works.

How does the gateway help with model risk management under SR 11-7?

The gateway enforces model risk management as expected under SR 11-7 and OCC 2011-12: only registered, approved models can be reached by any agent. New models and agents run alongside the bank's people before they are allowed to act. Approval comes from someone independent of the proposer, enforced by the system. When a model changes, agents relying on it automatically lose autonomy until re-validated.

Can we use the DLP and tokenization products we already have?

Detection is pluggable and combines several methods, the most certain first: the bank's own field definitions, validated patterns such as card numbers with checksums and bank and routing numbers, matching against records the bank already holds, its confidential term lists, recognition models for names and addresses, and optionally the bank's existing DLP system. Tokenization is pluggable too: NeodyAI's, or the tokenization product the bank already owns; detection can use the DLP system the bank already runs. No detection or tokenization service outside the bank's trust boundary ever receives its protected data.

What happens when the AI vendor changes its model?

When a model changes, agents relying on it automatically lose autonomy until re-validated. Tamper-evident records of every call, exportable for examiners, with no customer data in them.

Can it run on our premises, and is it available now?

Deployment: NeodyAI cloud isolated per customer, or protection on the bank's premises for card data and the most sensitive classes; the bank's own agents can use the gateway by registering and pointing their model and tool calls at it. The AI Gateway is being delivered in phases; availability for a given deployment is confirmed by contacting NeodyAI. A detailed architecture briefing is available under NDA.