Fintech app development: start with the rules, not the UI

Fintech app development: start with the rules, not the UI

A fintech app is easy to imagine and hard to ship. The screens — balances, transfers, a chart of spending — are the smallest part of the work. The rules underneath are the product: who can do what, what counts as money, and what happens when two systems disagree.

We have built trading systems, payment flows, and financial management tools at GlobeSoft, and the pattern is the same every time. The demo wins the meeting; the ledger keeps the customer.

Compliance is a product decision, not a checkbox

KYC, AML, data residency, audit trails. If you treat these as paperwork to bolt on at the end, you will rebuild the app at least once.

The smart move is to design the data model around compliance from day one. Every action gets a user, a timestamp, and an immutable record. Deletes do not really delete; they append a reversal. That one decision makes your audit trail possible and keeps you out of the conversations nobody wants.

Different markets add their own layers. A client in Singapore cares about MAS expectations. A client in Brazil cares about LGPD and Pix. A platform that serves Hong Kong, US, and mainland China trading has three rule books. The code that matters is the part that keeps all three straight.

KYC is also a conversion problem. Ask for too much and users drop off; ask for too little and you fail the regulator. The best teams treat onboarding as a product funnel and instrument it the same way, watching where people abandon the flow and trimming there first.

Money is a state machine, not a number

The moment you treat a balance as a single number you can add and subtract, you have a bug. Money moves through states: initiated, pending, cleared, settled, reversed, disputed. Each state has rules about who can move it forward and what happens if they do not.

The clean way to build this is with an explicit ledger and a reconciliation job that compares your records against the bank, the card network, or the exchange every day. On our trading build, settlement happened on different timelines per market, so the reconciliation jobs could not assume everything closed on the same day. That single detail changed the whole schedule.

A refund is not just negative money either. It is its own state with its own timeline, and it has to tie back to the original transaction so the ledger and the customer both see the same story.

Here is what the pieces usually look like:

Security is the default posture, not a feature

In fintech, security is not something you add at the end. Encrypt data at rest, use per-user session controls, and assume a credential will leak eventually. Log everything, and make sure the logs cannot be edited by anyone, including your own team. Use short-lived tokens, require two-factor for anything that moves money, and keep separate environments so a test credential never touches production.

The same goes for third-party integrations. A payment provider or a market data vendor will fail, return a timeout, or send you a file in a format that changed overnight. Your system has to degrade gracefully and flag the discrepancy instead of silently dropping money. In payments, silence is the most expensive bug there is.

What slows fintech projects down

It is rarely the code. It is the parts nobody wrote down at the start: which currencies, which countries, what happens on a partial fill, how disputes work, how long you keep records. Answer those on paper and the build gets a lot easier.

One more thing worth deciding early is who owns the payment rail integrations. They are the slowest external dependency, and they do not move on your schedule, so start those conversations before you write a line of UI code. Once the ledger and the rules are right, the rest of the product is mostly screens, and screens are the easy part.

We run these projects with a China-based team and a process tuned for clients in Brazil, South Africa, Singapore, and the US: a defined overlap window for live calls and a written trail for everything else. Finance, IoT, property, payments, whatever your industry is, if it is legal, we will build it.

Talk to us about your project