The real problem was one layer down.
I'd tackled reconciliation before, at a much larger scale [see: Data Reconciliation (Vertex)], and that domain knowledge is what let me push past the surface-level ask here instead of starting from zero again.
The brief was to improve reconciliation. Research said otherwise. The real problem sat one layer down: transaction-level issues were what made accurate reconciliation impossible in the first place. Fix reconciliation directly, and you're just designing a nicer experience around inputs that were never reliable to begin with. That's a losing bet. This is a dense, technical domain, so getting to that reframe meant building real background knowledge before any design work could start.
Validating the reframe before touching a direction.
I built the research plan and interview scripts myself, and ran both synchronous and asynchronous interviews. Competitive research showed how other tools approached similar transaction-and-reconciliation problems. Throughout, the goal was narrow and specific: confirm that transactions, not reconciliation, were the right place to intervene, before committing to a direction.
Starting at the bank account level.
- Logic builders let users define matching rules and conditions, building on rule-building patterns already validated in a prior project [see: Rule Builder Engine (Vertex)].
- Transaction matching surfaces as a task-based flow against incoming bank data.
- Comparison views put bank transactions side by side with internal records.
The flow also had to hold up against dozens of edge cases by the time it was fully worked through, given how many ways transactions can fail to line up across systems.
Still in development. Early stakeholder and user reaction to the concept has been strong, though it hasn't shipped yet, that part's worth saying plainly.