Problem
Legacy banking systems fail users when they encode a happy path and ignore the approval chains, exceptions and manual checks employees handle every day.
Workflow
- Intake.
- Assessment.
- More information when required.
- Approval.
- Fulfillment.
- Closure.
Architecture
The architecture should follow durable business objects rather than temporary screens. State transitions and ownership matter more than UI-first implementation speed.
In legacy banking contexts, the software has to respect existing process constraints while making the decision flow easier to inspect and maintain.
Decisions
Model permissions and state transitions before screens. Otherwise every page starts inventing its own business rules.
The banking process should be understandable as a workflow first: who can move a request forward, who can stop it, what evidence is required and which exceptions need manual review.
Lessons
Some complexity belongs in policy and process, not code. The software should make that boundary visible.