FDE On-Prem. Real-time fraud decisioning
that runs entirely inside your bank.
Your data stays on your infrastructure. Your PKI stays under your control. Your auditors get evidence, not promises.
Two install paths, one codebase
Pick the one that fits your bank's infrastructure team. Same decisioning engine, same dashboard, same audit evidence — different runtime.
Docker Compose
Single-host deployment. 5-service stack: engine, dashboard, PostgreSQL, Redis, nginx. Fastest way for bank infra teams to stand up a full evaluation environment.
- 1Drop the release tarball onto the host
- 2Pick
plain(HTTP) ortls(TLS 1.3 + mTLS) compose overlay - 3
gen-certs.shfor Mode A, or drop a bank-signed bundle for Mode B - 4
docker compose up -d— live
Ansible / bare-metal
No Docker required. 7 Ansible roles deploy engine, dashboard, PostgreSQL, Redis, nginx, pgbouncer, plus shared TLS role. Validated on a 2-VM topology (app VM + dedicated PG VM).
- 1Define your inventory (app host + PG host)
- 2Set
fde_tls_internal: truefor full-mesh mTLS - 3Mode A: Ansible generates CA. Mode B: drop bank bundle into
fde_tls_source_dir - 4
ansible-playbook -i inventory.ini site.yml
Architecture topology
The Ansible 2-VM reference layout. Every internal hop carries TLS 1.3 when fde_tls_internal: true.
nginx is not optional in multi-worker mode. Without it, HTTP keep-alive pins TCP connections to single uvicorn workers and throughput collapses. Auto-installed by the fde-nginx role.
pgbouncer is disabled by default. Benchmarks showed it added 5–20 ms with no throughput benefit because FDE workers maintain warm long-lived asyncpg pools. Enable only at >8 app-tier nodes.
pgbouncer + fde_tls_internal: true is incompatible in v1 — the Ansible role fails that combination intentionally. pgbouncer + TLS is on the roadmap.
Validated banking-tenant performance
Pre-configured banking fraud detection templates (full chain enabled), RTD internal lab, Intel Xeon E3-1245 v5. Lab measurements only — not a performance guarantee. Your hardware, network, tenant config, and rule mix will affect results.
- c=1
- 14.3 RPS · 56 ms
- c=5
- 41.7 RPS · 97 ms
- c=10
- 51.5 RPS · 173 ms
- 60 s sustained
- 55 RPS · 364 ms
- 60 s sustained
- 73 RPS · 262 ms
- P50 delta vs 2-VM
- -83 ms (co-located PG)
- TLS overhead
- <1% (AES-NI + reuse)
~23,000 banking evaluate requests across both topologies, zero errors (~13,500 Docker Compose TLS + ~10,000 Ansible 2-VM).
Same 2-VM lab, ecommerce tenant, plain HTTP: 70.4 RPS, P50 281 ms, P99 427 ms, 0 errors @ c=20. Represents a 3.5× improvement over the first-boot baseline on identical hardware with zero data loss — the headline banking numbers above build on this optimization.
Security & TLS posture
Zero-trust by default when you flip fde_tls_internal: true. Every internal hop is mutually authenticated.
| Hop | Protocol | Cert | Auth |
|---|---|---|---|
| Bank client → nginx | TLS 1.3 | Server (edge) | Server auth |
| nginx ↔ engine | TLS 1.3 | EC P-256 leaf | mTLS |
| engine → PostgreSQL | TLS 1.3 | EC P-256 leaf | mTLS sslmode=verify-full |
| engine → Redis | TLS 1.3 | EC P-256 leaf | mTLS rediss:// |
| dashboard → engine | TLS 1.3 | EC P-256 leaf | mTLS |
Two PKI modes
Audit evidence auditors can paste into their tooling
PostgreSQL emits a tls_connection event per connection with version, cipher, and verified status. Redis emits tls_handshake_verified at startup and on every reconnect (redis-py does not expose per-socket SSL metadata, so cipher/version are recorded as unknown for Redis).
# Count TLS 1.3 PostgreSQL connections over the last 24h jq -r 'select(.event=="tls_connection" and .tls_version=="TLSv1.3" and .verified==true)' \ /var/log/fde/audit.ndjson | wc -l # Any failed TLS verifications? jq -r 'select(.event=="tls_connection" and .verified==false) | {ts, peer, reason}' \ /var/log/fde/audit.ndjson
Queries map directly to FFIEC CAT, MAS TRM §10, and BNM RMiT §11 audit asks.
ansible-playbook --tags common,tls-rotate; Mode B banks reissue their bundle and operator reruns --tags common,tls (--tags tls-rotate is explicitly not supported in Mode B). Reload-not-restart where supported.
FDE TLS & Audit Pack
PDF posture summary, audit-query catalog (sample jq queries mapped to FFIEC CAT / MAS TRM §10 / BNM RMiT §11), and cert lifecycle runbook. Share it internally — no form gate, no lead capture.
Compliance posture
FDE ships with built-in rule-to-regulation mappings. We don't claim certification — we produce the evidence auditors use to certify your deployment.
FDE supports requirements such as those listed above. Consult your own counsel for formal compliance mapping. Data residency is a deployment property — FDE runs inside your data-residency boundary; cross-region data movement is your choice and your network fabric.
Talk to us about an on-prem PoC
30-minute technical walkthrough with the team that built it. We'll cover topology, TLS posture, cert lifecycle, and what an evaluation deployment looks like in your environment.
Talk to Us