Two-Server PII Isolation Architecture
A comprehensive look at how tPay365 separates business logic from personal data across physically isolated infrastructure.
The Problem with Conventional Architecture
Traditional fintech platforms consolidate everything into a single database: authentication credentials, business logic state, personal identifiable information, and payment details. A single vulnerability in any layer compromises the entire dataset. One SQL injection, one misconfigured endpoint, one leaked backup — and every user's bank details, national insurance numbers, and transaction history are exposed simultaneously.
Conventional Single-Server Architecture
A single breach exposes everything: names, bank details, transaction history, and authentication credentials.
tPay365's Split-Key Design
Server A — Business Logic
- HMAC-SHA256 hashing with HASH_PEPPER
- Auth, sessions, RBAC, rate limiting
- CleanPaycheck engine, yield accrual
- Vault reference storage (not PII)
"Knows what you owe, never who you are"
Server B — PII Vault
- AES-256-CBC encryption with AWS KMS
- BACS Standard 18 parser
- Vault API: store, retrieve, verify, delete, masked, batch
- Append-only audit log
"Knows who you are, never what you owe"
Communication Protocol
Server A initiates request with mTLS client certificate
Server B validates certificate + API key (timing-safe)
RBAC scope check against API key permissions
Operation executed, audit logged with actor and resource
Response returned over encrypted channel
Vault Reference Format
vault:{pii_type}:{uuid-v4}12 Supported PII Types
Threat Model
| Threat | Mitigation |
|---|---|
| Server A database breach | Only HMAC hashes and vault references. No plaintext PII to steal. |
| Server B database breach | Only AES-256 ciphertext. No business context to link data to identities. |
| Network interception | mTLS + TLS 1.3. Certificate pinning between services. |
| Insider threat | RBAC scoping, append-only audit, no single admin has full access. |