Financial products must remain clear after commitment
Tcules designs financial interfaces around eligibility, commitment, approval rights, supporting evidence, transaction state, exceptions, reconciliation and reversal.
- Financial products
- Commitment lifecycle
- Approval rights
- AI-enabled workflows
Financial clarity must survive the whole commitment
A person may complete a polished flow and still not know whether they received an estimate or an offer, or whether a payment is pending or failed. They may also be unable to see who can reverse an action, which evidence is missing or how to recover.
The product 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.
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 approval rights
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.
If clarity breaks after eligibility, consent or payment begins, bring the moment where the customer can no longer tell what state or obligation applies. Request free audit.
Authority and explanation are one design problem
The model connects each role with its authority, what the product must explain and the control that role needs.
| 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, what happens next and how to undo it | Review, consent, history and accessible support |
Adviser or agent | Prepare, recommend or submit within their approval limit | Basis, missing evidence, what the client will see | 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 risk 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.
The human-in-the-loop definition sets a practical test for whether review is timely, informed and able to change the outcome.
- 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 research the workflow, model roles and states, design the information architecture and prototype commitment and recovery paths. Approved decisions can continue into shared interface systems, frontend, backend, integrations, QA and AI-enabled functionality.
The client retains ownership of legal interpretation, regulated policy, financial models, underwriting, data ownership 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. Underwriting, compliance approval and a shipped financial outcome sit outside that public evidence.
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.
When this expertise is useful
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.
Share the current policy and workflow, decision roles, exception examples, system boundaries and available user or operational evidence. When approval or policy inputs are missing, the work records who must supply them instead of guessing the product rule.
Share 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.
Start a project
Share the product, market, user roles and the decision that is currently hard to explain.