One accounts API
Every client surface reads and writes through the same interface.

A fullstack banking platform — accounts API, mobile banking app and ops console built as one system — replacing a legacy pair of clients staff had learned to work around.
Start a Project
A teller desktop client and a customer-facing mobile app each reinterpreted KYC checks and audit logging in their own code, which is why no two surfaces recorded the same event the same way. Compliance spent more time reconciling what each system claimed had happened than reviewing whether it should have happened at all.
We refused to let either client own compliance logic. Every screen — teller desktop, mobile, ops console — was rebuilt to call one accounts API, with KYC checks and audit logging enforced once behind that interface rather than reimplemented in front of it three separate times.
An accounts API with encryption and audit logging enforced at the service layer, a mobile banking app and an ops console that read from it without drifting apart, and an audit trail the compliance team hands to regulators without translating it first.


Every client surface reads and writes through the same interface.
Checks live behind the API, not reimplemented in every client.
Every action is logged once, at the source, not per client.
Customer-facing accounts, transfers and statements on one shared core.
Staff-facing operations reading the exact data customers see.
One record of what happened, shared by every surface and every audit.


The client-side architecture and interface layer shipped for this engagement.

Services, APIs, and business logic running the system end to end.

Datastores and pipelines chosen for this engagement's consistency and throughput needs.

Deployment, orchestration, and delivery tooling running the platform in production.
Keeping two clients from re-diverging after launch
The old teller and mobile clients had drifted apart because each had somewhere to put its own logic. The new API exposes no client-specific endpoints, so there's structurally nowhere for either surface to fork behavior into.
Enforcing KYC once without slowing down the teller desk
Centralizing checks risked adding a network hop to every teller action. KYC state is cached at the API layer and invalidated on change, so a repeat check is a cache read, not a re-verification.
Encryption and audit logging without a throughput cliff
Per-field encryption on every write threatened peak-hour teller throughput. Encryption was moved to a write-through layer that batches key operations, keeping p99 write latency inside the desk's existing budget.
2 weeks
Mapped where the teller and mobile clients had silently diverged on KYC and logging.
3 weeks
The one-API rule was agreed with compliance before any client screen was touched.
3 weeks
Mobile, teller and ops flows designed in parallel against the same API contract.
9 weeks
Accounts API shipped first; all three clients built against it rather than a mock.
3 weeks
Compliance ran a full audit dry-run against the new log before go-live.
2 weeks
Rolled out branch by branch, teller desktop first, mobile app last.

“Compliance stopped asking which system was right. There's only one system now.”
Isabel Cruz · IT Director · Cobalt




Technical briefingNot a sales desk