Adopting AI in a large fintech
Choosing an agent stack by data, authority, risk, and platform maturity. Alexander Polomodov · T-Bank
Slide contents
1. Adopting AI in a large fintech
Choosing an agent stack by data, authority, risk, and platform maturity. Alexander Polomodov · T-Bank
2. “Ours or theirs” is a false choice
Open clients, local models, and MCP differ
Open source ≠ local inference
Self-hosted ≠ safe actions
Internal MCP ≠ narrow privileges
External API ≠ leak by default
3. An agent is more than a model
Governability appears only with identity and technically enforced execution boundaries
4. “Ours” means four controls
These properties do not imply one another and must be assessed separately
5. The three axes are independent
Each axis has its own data path, cost, failure point, and lock-in
6. A logo does not define the stack
Docs confirm capabilities, not deployment security
Observed
Open clients: OpenCode and Codex
Codex supports custom providers
Claude has multiple delivery paths
Not implied
Local, open model
Equal tool use
Sufficient sandbox
7. Control lives at two gateways
The model gateway governs data routing; the tool gateway governs authority and effect
8. 01. Eight configurations
Architectural patterns with different trade-offs in control, speed, and operations
9. Eight configurations on one map
Not a ranking but eight combinations of the data path and the authority path
10. Locality still requires operations
Two local modes
1 · Autonomous stack
Air gap and pinned versions
Full operational ownership
GPU, serving, evals, updates
3 · Client + local model
Ready-made UX and tool loop
Evals prove compatibility
The workstation remains the boundary
11. External reasoning, internal authority
Frontier planning; authority stays inside
2 · Owned harness
Owned process and tools
Frontier quality without owned GPUs
A gateway filters secrets
7 · Planner + executor
Only a typed plan leaves
Credentials stay inside
Policy checks business invariants
12. Speed costs trust
Separate vendor UX from corporate authority
4 · Agent + internal gateway
Strong UX and current model
Capabilities stay internal
OBO, policy, trace at gateway
5 · Full SaaS
Shortest time to pilot
Tenant, connectors, retention
High control-plane lock-in
13. Flexibility needs platforms
Routing needs evals; user stacks need boundaries
6 · Multi-model router
Price, quality, latency, region
Safe fallback by data class
Evals for every route
8 · User stack
Fast personal workflow
Shadow tokens, supply chain
Registry, scopes, test tenant
14. No universal configuration ranking
Properties depend on deployment context
Air gap requires configuration 1
A fast pilot points to 5
Enterprise actions point to 4
High risk points to 7
15. 02. Chain of authority
A threat model from user intent to the actual system change
16. Attackers target the data-to-action path
Each boundary adds a leakage channel, confused deputy, or goal substitution
17. Tool output is untrusted too
An issue, email, README, or log becomes another control channel
Label external data
Filter results and errors
Narrow subsequent capabilities
Test repeated attacks
18. Policy must be enforced technically
The model proposes an action; permission to execute it is checked outside the model
19. 03. How to choose
Start with the allowed data path, then the cost of action and operational ownership
20. Data first, products second
Three questions quickly narrow eight configurations to an admissible set
21. The baseline choice depends on deployment
Choose the smallest configuration enforcing required boundaries
Pilot · 4 / 5 — One repo, read-only or PR
Enterprise platform · 4 → 6 — Gateway and evals first
Regulated environment · 1 / 7 — Fail closed, OBO, sandbox
22. Hypothesis: two gateways anchor the platform
Multiple clients and models can operate around owned model and tool gateways
23. 05. Case: a large fintech
Testing eight configurations against scale, risk, and installed platform capabilities
24. Scale turns a choice into a platform
A local tool quickly becomes shared software-delivery infrastructure
10,000+ — Engineers — Thousands of repositories and stacks
55M+ — Customers — The blast radius keeps growing
regulated — Environment — Data, money, and 24/7
25. We are not starting from scratch
The model gateway, MCP/tool gateway, company context, and agent mode already define boundaries
26. A fintech has four hard constraints
Data, authority, resilience, and the supply chain must be governed together
27. The regulator expects system-wide governance
Threat model, security policy, supplier trust, and human validation of high-risk automatic actions
28. Six criteria filter out polished demos
Data and authority decide admissibility; operations and evidence decide fitness
29. Not all eight fit a large fintech
Two become core, three stay specialized, one is the next stage, and two remain sandboxed
30. 5 and 8 are not defaults
Fast adoption cannot offset opacity
5 · Full SaaS
Isolated low-risk pilot
Enterprise tenant, exported logs
Exit plan before connection
8 · Personal stack
Test tenant only
No work data or authority
MCP/version registry
31. 1 and 3 cover restricted environments
Locality trades GPUs and operations for autonomy
1 · Autonomous stack
Real air gap
Complete operational control
Highest ownership cost
3 · Client + local model
Sensitive local code
Compatibility through evals
The workstation remains a boundary
32. 7 keeps high-risk authority inside
External plan; internal executor verifies and applies
External planner
Allowed context only
A plan without credentials
Versioned schema
Internal executor
OBO and policy-as-code
Dry run and idempotency
Human validation for high risk
33. 2 and 4 anchor operations
Strategic owned agents and managed mass-market UX converge on one corporate control plane
34. 6 unifies the portfolio only after evals
Routing follows data class, quality, price, and availability without changing policy through hidden fallback
35. Sources establish properties, not rankings
Vendors, standards, regulation
OpenCode · Codex · Claude Code
GLM-5 · GigaChat API
MCP authorization · NIST · OWASP
Bank of Russia · personal data · bank secrecy
36. Fintech needs a configuration portfolio
2 / 4 are the core paths
6 follows private evals
1 / 3 cover restricted environments
7 controls high-risk execution
5 is an isolated pilot, 8 a sandbox
Own the paths of data, authority, and verification