Before a single screen gets sketched, most fintech projects start with mapping work that has nothing to do with visuals yet. A user experience agency for fintech spends this stage documenting how money, information, and decisions move through a product, since financial flows carry more branching logic than a typical app. This mapping work catches problems while they’re still cheap to fix, before a wrong assumption gets built into a finished screen. Skipping this stage tends to push those same problems into later development, where fixing them costs far more time and effort.
This groundwork covers several distinct areas before any flow gets designed, each one feeding into decisions made later during actual screen design. The three areas below come up across nearly every fintech project, regardless of what the specific product does.
User journey points
Journey mapping starts with identifying every point where a user makes a decision or takes an action, from opening the app through to completing a transaction. Financial journeys branch more than a typical app flow, since a single action like a transfer might trigger identity checks, balance verification, or a fraud review, depending on the amount involved.
A journey map tracks these points:
- Entry points, covering how a user arrives at each part of the flow.
- Decision points are marked where a user chooses between different paths.
- Exit points, showing where a user completes or abandons a task.
- Wait states, noting where a system needs time to process something.
Mapping all of this before design work starts gives a team a clear picture of where the flow gets complicated.
Regulatory checkpoints
Financial flows pause at specific points for compliance reasons, tied to identity verification, consent capture, or fraud checks, depending on the transaction type involved. These checkpoints get mapped alongside the user journey itself, since they shape how a flow gets structured well before any screen exists. Common checkpoints mapped at this stage include:
- Identity verification, triggered at account creation or before a first transaction.
- Consent capture is required before certain data is collected or shared.
- Fraud checks are applied to transactions crossing a specific amount threshold.
- Sanctions screening runs against names and details tied to a transaction.
Different transaction types often carry entirely different checkpoint rules, which makes this mapping work more involved than it first appears.
System dependencies
Every screen in a fintech flow depends on data from somewhere else. Mapping this reveals which screens need live data versus stored data, and shows the potential impact when one connected system runs slower than expected.
- Account balances are pulled from a core banking system in real time.
- Linked bank connections, verified through a separate authentication layer.
- Exchange rates are updated continuously from an external data feed.
- Third-party services, sitting outside the product but feeding data into it.
Screens relying on outside systems need a plan for what a user sees while that data loads, or when a connected service responds slower than expected. A flow built on this kind of groundwork holds up better once real users and real transactions start moving through it. The mapping work itself becomes the reference point against which every later screen gets checked.
