A mobile wallet designed so a bug can't move the money

The problem

People want to send money to family, pay power and water bills, buy airtime and take out cash without a trip to a bank branch. A wallet that does this has to earn trust twice. It must protect people from scams that trick them into paying the wrong person, and it must never lose or double-count a single cent of a local currency. PasinPay is my design for that wallet, aimed at urban smartphone users. Customer money would sit with a licensed partner bank, and PasinPay would run the app.

Constraints

• Design stage only. There is no live app, no production backend and no customer money.
• No partner bank, payment switch, identity service, biller or telco has agreed to anything. Every outside system is a simulator.
• Every fee, limit and time-out is a placeholder until the partner bank, the financial intelligence unit and legal counsel confirm it.
• The app has to be data-light, Android-first, and work in English and a local language.

What I did

Strategy and brand

I studied three established payment apps from public sources only (help pages, fee pages, regulator documents and news), with no decompiling and no copied text or artwork. Then I redesigned for the local market. A log of 87 recorded decisions settles conflicts between workstreams. I designed the logo, a short-name emblem and card designs for both major card networks.

Design

The wireframe covers 12 flows across 129 screens. The clickable prototype, built in React and TypeScript, runs every flow in a phone mockup with demo data, dark and light themes, and both languages. Scam protection is built into the flows. You see the payee's name and a match badge before you enter your PIN. Risky first payments wait an hour automatically. There is a "Someone tricked me" report, and SMS messages never contain links. The balance is hidden on Home, and lock-screen alerts are discreet.

Engineering

The backend starter is a NestJS and TypeScript modular monolith on PostgreSQL with a double-entry ledger. Prisma describes the structure. Plain SQL guards enforce the rules a schema can't express. Ledger and audit tables are append-only, every journal must balance when the transaction commits, customer balances can't go below zero, and a maker-checker request can't be approved by its maker. So the database refuses bad money data even if the app has a bug. Every money call needs an idempotency key, so the same tap sent twice debits once. Logins and payments are signed by a key bound to the device. The audit log redacts anything that looks like a PIN, code, key or card number. The changelog records 281 backend tests across 18 files, all passing.

AI

I designed and directed a team of 11 specialized AI agent roles in Claude Code that do the real work: a product lead, market research, regulation, UX, architecture, backend, mobile, integrations, risk, QA and business. They share one feature registry where every feature has an ID, each role writes only in its own folder, and they pass handoff notes instead of editing each other's work. Nothing is built without regulation and risk sign-off, and nothing ships without QA. One pipeline command takes a feature through every role in order. A consistency check runs on every build. It compares facts that live in several files, such as permission names, ledger postings and message keys, and stops the build when two files disagree.

Outcome

A clickable prototype of all 12 flows, a 129-screen wireframe, draft legal and policy documents, user and staff guides, and a working backend starter that runs against fake partners. Nothing is launched and no partner bank is signed. There are no users, and nothing has been measured.

What I'd change next time

I'd secure a partner bank conversation earlier. So many limits and fees are placeholders that some design work will need revisiting once real numbers arrive. I'd also have run the code review that found about 60 issues sooner, before the prototype and backend grew apart.