CIB Digital Banking

CIB's customers needed faster, more self-serve ways to manage cards and payments — activating Apple Pay, getting a new card without a branch visit, moving money into a mutual fund — without any of it compromising the controls a bank is required to have.

Banking software has a different failure mode than most software: a bug is not an inconvenience, it is somebody's money. Every feature here went through a heavier requirements and testing process than the equivalent would in a startup, for good reason. Specific internal architecture, data and metrics are not shown here — this is a description of the process and my role in it, not the system.

I work across the stack on the features listed below: gathering requirements alongside product owners and business stakeholders, writing the backend services and REST APIs, documenting the API contract for other teams, and supporting UAT through to release.

• Sat in requirements sessions with product owners and business stakeholders to turn a business ask into functional and technical requirements
• Worked with QA and frontend engineers so a spec was implementable and testable before a line of code was written
• Wrote API documentation and technical specifications used as the contract between business and engineering
• Ran system testing, defect resolution and User Acceptance Testing with the people who would actually sign off the feature

Backend services built with Node.js and NestJS, exposed as documented REST APIs, feeding a React and React Native frontend. The CIB × WE portal is the clearest example: it integrates backend APIs to surface real-time payment information and transaction updates for customers, replacing what used to require a manual check.

• Treated API documentation as a deliverable, not an afterthought — it is what let frontend engineers, QA and business stakeholders work from the same source of truth instead of reverse-engineering behaviour from a running service
• Built UAT into the delivery process rather than bolting it on at the end, so defects surfaced against real business scenarios before release, not after

• Regulated features like Apple Pay activation and mutual-fund trading carry compliance requirements that a typical product feature doesn't — every requirement had to be traceable back to a business or regulatory need, which slows the first pass but prevents expensive rework later
• Coordinating a spec across product owners, QA and frontend engineers who each read a requirement differently is a real skill, and the biggest lesson has been writing specifications specific enough to remove ambiguity without making them so rigid they can't absorb a late-stage business change

• Shipped Apple Pay activation, Instant Card Issuance, Real-Time Deposit Redemption and Mutual Fund Trading
• Designed and built the CIB × WE portal

The best banking engineers are not the ones who write the cleverest code — they are the ones whose spec a QA engineer, a product owner and a backend developer can all read the same way. That skill transfers to every team I've worked with since.