FinTech and InsurTech
Financial products must remain clear after commitment, when money moves, obligations begin, claims change state or authorised people make decisions with consequences.
- Financial products
- Insurance journeys
- Authority models
- Recovery paths
A clean screen is not enough
A person may complete a polished flow and still not know whether they have received an estimate or an offer, whether a payment is pending or failed, who may reverse an action, which evidence is missing, or how to recover.
The product model must answer those questions before visual simplification can be trusted. In this category, clarity includes what the person may do, what the organisation may do, what has already happened and which state is still provisional.
Tcules designs these products around eligibility, commitment, authority, evidence, transaction state, exceptions and recovery. Legal, risk, compliance and underwriting decisions remain with the client and its qualified advisers. Tcules' responsibility is to make the approved rules and their consequences usable, inspectable and implementable.
The commitment lifecycle
- 01
Eligibility
Show what can be assessed, which evidence is required and which conclusion remains provisional. An estimate should not look like approval. When a rule cannot be exposed directly, the interface should still explain the next step and the evidence needed.
- 02
Offer and comparison
Keep amount, term, fee, exclusion, obligation and meaningful alternative close enough to compare. Progressive disclosure can reduce cognitive load, but it should not separate the attractive headline from the condition that changes its meaning.
- 03
Consent and authority
Consent should correspond to the real action. The person needs to know what they are authorising, in which role, and what happens next. In multi-role products, the preparer, approver, operator and account holder may require different evidence and controls.
- 04
Processing and state
Distinguish submitted, authorised, pending, failed, reversed, settled, disputed and refunded where those states apply. A spinner is not a transaction model. Each state needs an owner, time implication and permitted next action.
- 05
Exception and recovery
Explain what happened, what remains safe, whether the action can be retried, which information is preserved and which authorised route can resolve the issue. Recovery is part of the main journey, not an edge screen designed after launch.
Authority and explanation are one design problem
The table shows how different roles require different authority, explanations and controls in consequential financial or insurance workflows.
| Role | Authority | What the product must explain | Control the role needs |
|---|---|---|---|
Applicant or customer | Supply evidence, accept or decline, authorise eligible actions | Status, material terms, consequence and recovery | Review, consent, history and accessible support |
Adviser or agent | Prepare, recommend or submit within assigned authority | Basis, missing evidence, client-visible consequence | Draft, compare, record rationale and hand off |
Operations reviewer | Verify, request evidence, approve, return or escalate | Rule applied, source, history and exception | Queue, evidence view, reason and audit trail |
Administrator | Configure roles, limits and product rules | Affected people, effective time and inherited access | Preview, dual control where required and reversal path |
Helpful friction, not obstructive friction
Some friction protects a decision. Reviewing the recipient and amount before a transfer, comparing a changed policy term or confirming the scope of an AI-assisted action may slow the flow for a useful reason.
Friction becomes obstructive when it hides information, forces repetition without reducing risk, uses urgency against the person or makes refusal and recovery harder than acceptance. The design question is not how to remove every step. It is which uncertainty or consequence the step resolves, and for whom.
How AI changes the category
AI can classify documents, retrieve evidence, summarise an account, explain a rule, detect an anomaly or recommend a next action. Those capabilities introduce a second state model alongside the financial one:
- what information the model used;
- whether the output is a draft, recommendation or authorised action;
- how confidence and uncertainty are communicated;
- which role reviews or overrides it;
- what is recorded for later inspection;
- what happens when the model or input is wrong.
The product should not make probabilistic reasoning look like a settled financial state. A generated explanation also cannot replace the client's approved disclosure or advice process.
How Tcules shapes the product
Depending on scope, Tcules can conduct product and workflow research, model roles and states, design information architecture and interaction, prototype commitment and recovery paths, develop shared interface systems, and carry approved product decisions into frontend, backend, integration, QA and AI-enabled functionality.
The client retains ownership of legal interpretation, regulated policy, financial models, underwriting, data authority and final production approval. Market and product boundaries are agreed before design claims are made.
Relevant evidence, kept within its boundary
The OctiFi case covers product design for a bounded mobile lending experience. It does not establish underwriting, compliance approval or a shipped financial outcome.
The Kirana research case records research into merchant payment work. It supports the value of observing real operating context, not a claim that Tcules built or improved a payment platform.
Does this fit your product condition?
This work is relevant when a financial or insurance product has consequential states, multiple roles, evidence-heavy decisions, recovery paths or AI entering an approved workflow. It is not a substitute for compliance, legal, underwriting or financial advice.
Bring the product, market, user roles and the decision that is currently hard to explain. Tcules can determine whether the first useful move is research, product modelling, an audit, design or delivery.
Discuss the financial product condition
Bring the product, market, user roles and the decision that is currently hard to explain.