A practical checklist before building a fintech product

A fintech product is a set of promises about money: who can move it, what is recorded, and who can explain the record later. The checklist below is the work to do before a build, not a claim that any of it makes you compliant. Licences and certifications depend on your jurisdiction and on the activity you actually perform. A software partner can build controls. It cannot award you a permission.

Write down the activity in one sentence

Say what the product does in language a customer would recognise. “People hold a balance and send it to each other” is different from “we introduce borrowers to lenders” and different again from “we move card payments for merchants.” The sentence decides which rules you and your counsel need to read. If you cannot write it, you are not ready to model a database.

Name what you will not do in the first release. A wallet that also underwrites loans is two products. Shipping both because the pitch deck showed both is how ledgers get muddy.

Give every amount a home in the ledger

Before screens, agree the entries. A useful ledger can answer, for any balance, which entries created it and whether a later correction is a new entry rather than a silent edit. If a figure on a dashboard cannot be traced to entries, it is a picture, not a record.

Decide the currency, the smallest unit you store, and what happens to a payment that is authorised but not captured, or captured and then reversed. Those states are the product. The happy path is the easy part of the diagram.

Separate who may act

List the roles: the customer, the support agent, the reviewer, the person who can move funds, and the person who can approve that move. If one login can create a beneficiary and approve the payment, you have an avoidable fraud path. Role-based access is not a setting you add at the end. It is the shape of the API.

Add an audit trail for the actions that change money or identity: who did it, when, and from which role. You will need that trail the first time a customer disputes a transfer, whether or not a regulator asks.

Treat identity as a workflow, not a checkbox

Know-your-customer collection is a queue of documents and decisions. Specify what you collect, where it is stored, who can open it, and how long you keep it. Encrypt it in transit and at rest. A vendor may perform the check. You still need a place for a person on your side to see the result and record an accept or a reject.

Do not let an automated score be the only decision on a case your policy says a person must review. If you do not have that policy yet, write it with counsel before the workflow is built around a guess.

Plan the failures you already know

Duplicate requests, a customer who taps pay twice, a partner that times out after you have debited, and a file of payouts that fails halfway through. Each of these needs an idempotent behaviour: the same request does not move the money twice, and a partial file can be continued or reversed with a record of both.

Also decide what a customer sees while you do not yet know the outcome. “Pending” is acceptable. A success message you cannot support is not.

Leave compliance as a scoped list, not a slogan

Make a list, with your counsel, of the duties that apply to the activity in the sentence you wrote. Mark which of those duties are product behaviour, which are operational (a person, a vendor, a report), and which are not yours. Build only the product behaviour you have agreed. Do not put “bank-grade” or “fully compliant” on the site. Those phrases are not a design.

When the checklist is answered in writing, a build can start on a narrow slice: one ledger, one role model, one payment path, and a review queue. Everything else is a later release.