Draft
Required information is incomplete or not submitted.
Next: Show exactly what is still required.
Fintech
Make high-stakes states understandable without letting UX invent policy.
Financial onboarding is trustworthy when the interface explains what state the application is in, what evidence is missing, what can be corrected and which approved rule or system controls the decision.
Application lifecycle
1Intent
2Submit
3Verify
4Decision
5First use
Application state model
Every state needs a reason the user can act on.
The interface should expose progress without revealing or inventing policy logic it does not own.
Submitted
The application is durable and awaiting verification.
Next: Prevent accidental duplicate submission.
Needs correction
Specific information can be corrected or resubmitted.
Next: Explain the permitted correction path.
Under review
An approved system or operator is evaluating evidence.
Next: Do not imply approval.
Approved / declined
The authoritative decision exists.
Next: Show allowed next steps and support route.
Policy boundary
Good UX explains policy state; it does not become policy.
The product experience can make a rule understandable while leaving the actual decision with the approved policy engine or operator.
✓
Eligibility rules should be explicit in authoritative systems, not inferred by client-side logic.
✓
Verification results should reference approved evidence and permitted disclosure.
✓
A model or UI recommendation should never silently promote a user to an approved state.
✓
Recovery and support paths matter as much as the happy path.
Correction path
A user submits an application with a document that cannot be verified.
The trustworthy experience separates “verification failed” from “application declined.”
Keep the application durable
Do not force the user to rebuild unrelated information.
Name the correctable item
Explain what evidence needs replacement or review without exposing restricted policy logic.
Return to review
After correction, the authoritative verification flow resumes from a known state.
Exception / boundary
If policy forbids correction, the interface should say so directly and route to the permitted support path.
What this proves
The user understands the state and next action without the interface pretending to decide financial eligibility.
Next step
When an application moves between verification and decision, can the user tell what changed?
Bring one onboarding or account transition, the evidence it depends on, and the authoritative rule or system that owns the decision.