Self-serve reconciliation, and the trust we had to earn back

Context

Transaction Junction sits between retailers, banks, payment providers and value-added service providers as the switching and infrastructure layer. We set out to launch a self-serve reconciliation product as part of a broader redesign of the payment ecosystem and its value proposition. Reconciliation is a mature, well-served category, and most of our target merchants were already comparing us against established enterprise-grade reconciliation engines.

The problem

We were taking an MVP to market against that benchmark, which meant the product had to earn trust before it could earn adoption. In a financial product, trust is not a feature you add later. The customer is comparing what our product shows them against something they already trust: the bank's own mark-off file and their own spreadsheet.

My role

I owned product vision, prioritisation and commercial readiness across the merchant and end-user payments value chain. I gave one product manager and one designer full autonomy to run customer interviews and shape the product from what they heard. My job was to hold the view of whether what they were hearing could scale across the whole merchant base, to challenge assumptions, remove blockers, and keep Commercial, Engineering, CS and Support aligned around the same customer outcome rather than optimising independently.

What we did

• Ready to sell: established pricing that reflected an MVP rather than a full enterprise suite, clear positioning on what the product did and did not yet cover, and a demo environment showing real reconciliation behaviour rather than mock data.
• Ready to deliver: worked through transaction volume, variability across bank and merchant integrations, and the matching criteria needed to tie a transaction on our side to its entry in the bank mark-off file. Product and Engineering jointly owned the timeline.
• Ready to operate: prepared rollout sequencing, customer onboarding and configuration, documentation and operational dependencies, so the product could be implemented consistently across different merchant environments.
• Ran discovery through the PM and designer directly with different merchant personas, rather than designing for an assumed finance user.

Outcome

• Accuracy problems appeared after launch. We were matching transaction types we did not have full visibility into, so merchants saw mismatches that were not errors, just gaps in our matching logic. That eroded exactly the trust we had been building.
• Product, Engineering and Support ran as a single task team. Support fed recurring issues back through structured feedback loops while Engineering isolated the matching logic.
• We returned to the mark-off file specification, identified matching identifiers usable consistently across the transaction flow, and redesigned the interface to separate positive and negative flows with clearer context on what the data meant and how to act on it.
• Three weeks from diagnosis to fix. Client queries dropped sharply, trust was restored, and we retained the customer relationships that had been most vocal about the accuracy issues.

What went wrong, and what I learned

Sales had committed to capabilities, including three-way reconciliation and coverage across all transaction types, that Engineering could not deliver on the original timeline. My instinct at the time was to frame that as outside our control, a technical gap we had not foreseen. On reflection that is not quite right. The real issue was that we had not drawn a hard enough boundary between what Sales could commit to and what had actually been certified and tested. That is a Product accountability gap, not an engineering surprise, and it is the clearest lesson I took from this. I would now put a commercial-to-technical certification boundary in place before Sales starts positioning capability commitments.

Back to all work