Project
A working digital bank — accounts, payments, cards and lending on a real double-entry ledger, on the web and on Android.
What it is
ToskTech Banking Suite is a retail banking platform you can actually sign into. Open an account, move money between people and accounts, manage a card, pay bills, set up a direct debit, apply for a loan, verify your identity, and pull a statement — from a browser or from an Android app that talks to the same APIs. Behind the customer app sits the other half of the job: an operations console for KYC queues, AML cases, audit trails, and support. It runs live at banking.tosktech.com as a demonstration bank on seeded data, so the whole product can be walked through end to end without a licence or anybody's real money.
Architecture
A .NET 9 core banking API carries the domain — accounts, transactions, payments, cards, lending, savings, FX, trading, crypto, and compliance — with PostgreSQL and EF Core underneath and a React single-page app served by nginx in front. Around the core sit nine smaller ASP.NET services for the verticals: lending, insurance, international, cards, ATM and cash, security and compliance, AI, the admin backoffice, and an integrations service that hosts the open-banking surface over REST, GraphQL, and gRPC. The core doubles as the backend-for-frontend, proxying to those verticals over cluster-internal HTTP behind a shared service key, so the browser only ever talks to one origin. Statements and app releases live in Ceph object storage behind an S3 interface, and live balances and market ticks push to clients over SignalR. A Jenkins pipeline runs the .NET, web, and mobile test suites, audits dependencies for known vulnerabilities, builds eleven images, pushes them to a private registry, and applies the Kubernetes manifests.
The ledger underneath
Money does not move by updating a balance column. Every transfer, fee, interest accrual and direct debit goes through a posting engine that writes a balanced double-entry journal — debits must equal credits or the entry is rejected — inside a serializable database transaction that retries when the database refuses to serialise it. Balances, holds, and the customer-facing transaction list all fall out of that single write. Side effects are queued to a transactional outbox in the same transaction, and every money-moving request carries an idempotency key, so a retried payment replays its original response instead of posting twice. An end-of-day job runs interest accrual, dormancy marking, statement cuts, and SEPA direct-debit collection through the same engine, so nothing takes a shortcut around the ledger.
Notable engineering
The regulatory surface is where the interesting problems are. Strong customer authentication uses dynamic linking: the one-time code is bound to the specific payment instruction, so a challenge captured for one transfer cannot approve another. Verification of Payee checks the beneficiary name against the account before the money leaves, through an external provider with a sandbox responder to fall back on. IBANs are validated and generated with per-country mod-97 check digits. Sanctions screening, AML rules, and case management run against bundled OFAC, EU, and UN lists; the audit log is a hash chain, each event sealed with the hash of the one before it, so tampering shows. Open banking is consent-gated account information under PSD2; card numbers and security codes sit encrypted behind a tokenising vault; GDPR export and erasure, annual FATCA and CRS reporting, and an EU/UK/US data-residency router are all wired in. The web app ships in six languages, web and mobile are held to a written feature-parity matrix, and the Android build comes out of the same pipeline and downloads straight from the site.
Building something with money in it?
Ledgers, payments, and the compliance machinery wrapped around them — that is the part I enjoy. Tell me what you're building.