Project overview
Long-term product work across a complex financial operations platform.
This was not one feature or one visual redesign. I worked across customer discovery, reconciliation workflows, exception management, interface improvements, design-system evolution, onboarding, and the early product direction for a ground-up rebuild.
The scope
Improve what existed while helping define what the product should become.
I joined customer calls, translated operational needs into product requirements, designed new features, refined daily workflows, collaborated with engineers and product managers, and helped build a stronger product foundation over time.
What reconciliation means
Reconciliation turns transaction differences into work that teams can resolve.
Financial reconciliation compares records from different sources to confirm that money moved as expected. Matching records can move forward. Unmatched records require teams to understand what is missing, duplicated, delayed, reversed, incorrectly formatted, or recorded with a different value.
- 01
Data sources
Internal records, bank files, processors, settlements, and partner exports.
- 02
Import or sync
Bring records into a structured reconciliation process.
- 03
Match
Compare records across sources and identify differences.
- 04
Review
Move unmatched records into an investigation workflow.
- 05
Resolve
Resolve, assign, or escalate the exception with context.
- 06
Report
Preserve outcomes for finance, operations, and management.
Reconciliation is not just about matching records. It is about helping teams understand what went wrong, what needs attention, and what can be trusted.
My role over time
This was long-term product work, not a single redesign.
My work moved between customer discovery, feature design, workflow improvements, interface refinement, and product strategy. Some days focused on customer feedback. Others focused on technical constraints, design-system decisions, or the future structure of the product.
The product started with strong engineering logic. My work helped move it toward a clearer, more usable, and more scalable product experience.
Learning from customers
Customer calls shaped how the product evolved.
Reconciliation is not a generic workflow. Customers may use different file formats, sources, business rules, reports, and exception types. Listening directly helped me understand where teams lost time, which information they needed first, and which requests pointed to reusable product patterns.
What needs attention
Which jobs, records, or exceptions should a team review first?
Why a record failed
What evidence explains the mismatch or processing issue?
What happens next
Which action is available, and who is responsible for it?
What supports a decision
Which financial details need to remain visible during review?
Where setup breaks down
Which onboarding steps create delays or repeated support work?
What can become reusable
Which customer request points to a broader product pattern?
How could we help finance and operations teams match, investigate, and resolve transaction records with greater clarity and less manual effort?
Product model and exceptions
The most important work began when records did not match.
Matched transactions often required little attention. Exceptions were where teams spent most of their operational time. The product needed to show why a record required attention, preserve the relevant detail, make the available action clear, and retain a dependable resolution history.
Data import
Bring transaction records into the product and make processing state visible.
Matching
Compare records across sources and distinguish matched activity from exceptions.
Exception work
Review mismatches, understand context, and move each item toward resolution.
Job status
See what completed, failed, remains pending, or needs attention.
Reports
Share reconciliation outcomes with finance, operations, and management teams.
Customer setup
Collect the requirements needed to configure a dependable reconciliation process.
Move from mismatch to a recorded resolution.
Exceptions were not edge cases. They were a primary product journey.
- 01Unmatched record
- 02Exception created
- 03Review details
- 04Investigate mismatch
- 05Resolve, assign, or escalate
- 06Resolution recorded
Improving the product in layers
Small improvements gradually revealed the need for a larger change.
Customer feedback led to workflow changes. Repeated usability issues led to better tables, filters, statuses, empty states, and navigation. New features exposed gaps in the visual language and component system. Each improvement helped, but also made the limits of the original architecture more visible.
- 01
Engineering-led product
The first version proved that the technical reconciliation system could work.
- 02
Customer feedback
Calls and support patterns made recurring operational friction visible.
- 03
Workflow improvements
Individual journeys became clearer, more predictable, and easier to act on.
- 04
Interface and theme updates
Tables, filters, statuses, navigation, and visual hierarchy became more consistent.
- 05
Design-system evolution
Shared patterns helped a growing product feel more coherent across features.
- 06
Decision to rebuild
The limits of incremental improvement pointed to a deeper architectural problem.
- 07
Redesign exploration
I began the product and workflow foundations for a ground-up rebuild.
Interface and design system
A shared system for a growing operational product.
The product used Ant Design as a technical foundation. My work involved adapting that foundation into a more intentional product language rather than treating the default library as the finished design system. This was an ongoing evolution, not a one-time visual refresh.
Ground-up redesign exploration
When incremental improvements were no longer enough.
Over time, it became clear that the product needed more than another round of interface changes. Its layout, information architecture, workflow hierarchy, and customer setup model needed to be reconsidered together.
Before leaving Credrails, I began the foundational work for a ground-up redesign. I explored a clearer navigation model, reconciliation job structure, exception flow, table patterns, reporting, customer configuration, and the path from data import to matching and resolution.
The redesign was not completed or launched during my time at the company. My contribution was the early product thinking and structural direction for a more coherent rebuild.
After many incremental improvements, the next step was to rethink the product from the ground up. I started that work before leaving the company.
Onboarding and related work
Improving the experience before reconciliation begins.
A customer's experience starts before the first reconciliation job. Different data sources, file formats, business rules, and reports can make implementation demanding. I worked on a guided auto-onboarding direction to collect those requirements more clearly.
Bring structure to customer setup.
The intended benefit was clearer inputs for implementation teams and a more manageable path to configuration.
- 01Business requirements
- 02Data sources
- 03Reconciliation rules
- 04Reporting needs
- 05Implementation review
- 06Structured setup
Selected product screens
The operational experience, from overview to recovery and support.
These screens show how the product brought reconciliation health, source comparison, file ingestion, validation, and self-serve support into one connected operational system.
A shared view of reconciliation health.
The dashboard brings transaction volumes, matched and unmatched records, balances, fees, and cashflow into one operational overview.
Compare records across three financial sources.
This view makes the relationship between ledger records, bank statements, and processor data visible before teams investigate discrepancies.
Make processing state visible from the moment data enters.
Teams can filter uploads, understand processing outcomes, compare record counts, and move directly into a reconciliation summary.
Explain the issue and preserve a clear way forward.
A focused validation state catches an incorrect reconciliation date while giving the operator a safe correction path without losing context.
Support adoption beyond the core workflow.
Documentation, tutorials, guides, and frequently asked questions give finance teams a self-serve path through unfamiliar reconciliation work.
11 · Outcome and reflection
A stronger foundation for complex financial operations.
Customer-informed product work
Product decisions stayed connected to real reconciliation and implementation needs.
Clearer operational workflows
Matching, status, exception review, and next actions became easier to understand.
A more coherent interface
Shared patterns improved consistency across a growing financial operations product.
A stronger future direction
The early rebuild work reframed the product around a more deliberate architecture.
Working on reconciliation moved me deeper into fintech infrastructure. It taught me how to design for data-heavy systems where accuracy, status, onboarding, exception handling, and trust all shape the experience.
Those lessons later influenced how I approached founder-led products such as Remllo Watchtower, Remllo Identity, and Remllo Compliance. The context changed, but the underlying questions remained familiar: what needs attention, what can be trusted, and what should happen next?
Good financial infrastructure design makes operational complexity easier to see, understand, and act on.