Bitpanda Custody Platform
Backend work on an institutional crypto-custody platform for banks — where correctness, auth, and auditability are the product.
The problem
Bitpanda was building an institutional crypto-custody platform for banks — infrastructure that lets regulated financial institutions hold and manage digital assets for their customers. Correctness, authentication and auditability are most of what a bank is evaluating when it decides whether to use a custody platform.
Banks needed a safe way to manage and validate the crypto addresses their customers withdraw to. A wrong address in custody can mean funds nobody gets back. I owned the address book, built and expanded authentication between services, and added test coverage.
How I approached it
I owned the crypto address book from design through to production, on a backend built with Fastify, GraphQL and TypeScript running on AWS microservices and serverless. It manages and validates customer crypto addresses, so the validation rules, edge cases and failure modes were the requirements rather than details to handle later.
I also built and expanded authentication between services, and added backend test coverage for the parts I worked on.
The team was three backend and four frontend engineers, a designer and a product owner.
Key technical decisions
Validation first
Addresses have to be validated before they can ever receive funds, so the validation rules and edge cases were the main design work rather than an afterthought.
Owning the whole slice
API design, data model, validation, tests and release, rather than task-by-task execution.
Auth across service boundaries
Built and expanded authentication between services on an AWS microservices and serverless architecture, where services trusting each other by default would have been part of the risk.
Test coverage
Added backend tests for the services I worked on, so changes could be checked by running them rather than by review alone.
What it was for
The address book gave banks a validated, auditable way to manage where customer crypto can move, which a custody platform needs before it can offer the service at all. Exact platform metrics aren't mine to disclose; the custody domain doesn't publish its numbers.
What I took away
In most products an edge case is a bug you fix later. Here it can be money that moves and does not come back, so I got used to starting from the failure cases and letting those decide the API shape, the validation and the tests.
The other thing I took from it was how much of the job is explaining risk to people who are not going to read the code.