A_GUZMAN c-copper v0.03
← 02_WORK / FINTECH-AI
[0x01] AI_FINTECH // BANKING_LLM

An on-prem LLM gateway for a bank that cannot send data out.

On-premise LLM platform for financial institutions, architected in C#/.NET. Multi-provider model routing, RAG pipelines with vector search, multi-agent orchestration — and a hard requirement of zero external data egress. Employer and client names withheld; specifics under NDA.

ROLE
Architect, gateway & retrieval
STACK
C#/.NET, RAG, vector search
CONTEXT
Core banking, regulated
EGRESS
None — by construction
STATUS
Active — professional work
01 // THE_CONSTRAINT

Regulation set the architecture before I wrote a line.

Banks want LLM capability — document understanding, retrieval-augmented answers, agent workflows — but regulation and risk mean customer data cannot leave the building. Public-cloud AI APIs are a non-starter; every byte must stay on infrastructure the institution controls. That turned the project into an infrastructure problem first and a model problem second.

The gateway's job: give internal teams one API surface for AI capability, run entirely on-premise, with the same reliability bar as any other core-banking dependency.

02 // ARCHITECTURE

One gateway in front of local inference.

A .NET gateway owns authentication, request shaping, quotas, and audit logging. Behind it, a model router normalises local providers behind one contract; a RAG pipeline chunks, embeds, and searches internal documentation; an orchestrator splits multi-step questions across bounded, logged agents. Sanitized diagram.

on-prem boundary — egress to public AI endpoints: none

RAG pipeline

chunk

embed

vector search

prompt assembly

internal apps

gateway API (C#/.NET)

auth / audit / quotas

model router

provider A (local)

provider B (local)

model

agent orchestrator — multi-step, bounded, fully logged

EDGE
.NET gateway
Auth, quotas, request normalisation, audit write-through.
ROUTE
Model router
Providers behind one contract; swapping engines is config.
RECALL
RAG pipeline
Chunk → embed → vector search → prompt assembly, each stage tunable.
PLAN
Orchestrator
Multi-step agent workflows — deliberate, bounded, logged.
03 // DECISIONS
D1

Provider abstraction first

Models change monthly. The routing layer normalises providers behind one contract so swapping engines is configuration, not code.

D2

RAG as a pipeline, not a library call

Chunking, embedding, vector search, and prompt assembly are explicit stages — each one tunable and auditable on its own.

D3

Zero egress as an architectural property

Not a policy document: the deployment has no route to external AI endpoints. Compliance can verify it by reading the network, not the handbook.

D4

C#/.NET, because the institution can operate it

Multi-agent orchestration for workflows where one model call isn't enough — deliberate, bounded, logged — in the stack the bank's own teams can extend and audit.

04 // PROPERTIES
0 bytes
External data egress.
multi
Providers behind one API.
RAG
Vector search + retrieval, on-prem.
full
Audit trail per request.

Throughput and deployment specifics are the client's to share, not mine. The personal-lab equivalents of every moving part here — RAG bot, embeddings store, agent deliberation — run on my own hardware and are documented on the fintech-ai page.