Skip to content
Podlodka AI logo composed of source-code characters
Podlodka AI Engineers Club · August 4, 2026
Architecture × Security

Adopting AI in a large fintech

Choosing an agent stack by data, authority, risk, and platform maturity. Alexander Polomodov · T-Bank

/ Podlodka AI · Agent stack for a large fintech

Slide contents

  1. 1. Adopting AI in a large fintech

    Choosing an agent stack by data, authority, risk, and platform maturity. Alexander Polomodov · T-Bank

  2. 2. “Ours or theirs” is false

    Open clients, local models, and MCP differ

    Open source ≠ local inference

    Self-hosted ≠ safe actions

    Internal MCP ≠ narrow privileges

    External API ≠ a leak by default

  3. 3. An agent is more than a model

    Governability appears only with identity and technically enforced execution boundaries

  4. 4. “Ours” means four controls

    These properties do not imply one another and must be assessed separately

  5. 5. The three axes are independent

    Each axis has its own data path, cost, failure point, and lock-in

  6. 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. 7. Control lives at two gateways

    The model gateway governs data routing; the tool gateway governs authority and effect

  8. 8. 02. Eight configurations

    Architectural patterns with different trade-offs in control, speed, and operations

  9. 9. Eight configurations on one map

    Not a ranking but eight combinations of the data path and the authority path

  10. 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. 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. 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. 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. 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. 15. 03. Chain of authority

    A threat model from user intent to the actual system change

  16. 16. Attack path: data to action

    Each boundary adds a leakage channel, confused deputy, or goal substitution

  17. 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. 18. Policy must be enforced technically

    The model proposes an action; permission to execute it is checked outside the model

  19. 19. 04. How to choose

    Start with the allowed data path, then the cost of action and operational ownership

  20. 20. Data first, products second

    Three questions quickly narrow eight configurations to an admissible set

  21. 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. 22. Hypothesis: two gateways anchor the platform

    Multiple clients and models can operate around owned model and tool gateways

  23. 23. 05. Case: a large fintech

    Testing eight configurations against scale, risk, and installed platform capabilities

  24. 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. 25. We are not starting from scratch

    The model gateway, MCP/tool gateway, company context, and agent mode already define boundaries

  26. 26. A fintech has four hard constraints

    Data, authority, resilience, and the supply chain must be governed together

  27. 27. The regulator expects system-wide governance

    Threat model, security policy, supplier trust, and human validation of high-risk automatic actions

  28. 28. Six criteria filter out polished demos

    Data and authority decide admissibility; operations and evidence decide fitness

  29. 29. Not all eight fit a large fintech

    Two become core, three stay specialized, one is the next stage, and two remain sandboxed

  30. 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. 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. 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. 33. 2 and 4 anchor operations

    Strategic owned agents and managed mass-market UX converge on one corporate control plane

  34. 34. 6 unifies the portfolio only after evals

    Routing follows data class, quality, price, and availability without changing policy through hidden fallback

  35. 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. 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