The Decision
A fintech company with 2 million pay points was generating data it couldn’t use.
The client provides financial technology and services across the financial services sector – a business whose revenue model depends on the quality, timeliness, and usability of the transaction data flowing through its platform. At peak load, that platform processes more than 12,000 transactions per second across 2 million merchant pay points. That volume represents an extraordinary commercial asset.
The problem was that none of it was accessible in any meaningful sense. Data lived in disconnected silos across business units. There was no unified view of what was happening across the merchant base, and no way to offer merchants a window into their own transaction activity. The platform was generating intelligence continuously – and discarding it, equally continuously, because there was nowhere for it to go.
The question wasn’t whether to modernize the data platform. It was whether to do it in a way that would unlock monetization, not just improve internal reporting.
The Problem, Reframed
The legacy platform wasn’t failing. It was succeeding at the wrong things.
The existing infrastructure was doing what it had been designed to do: move transactions through. Data quality was an afterthought rather than a discipline. Integrations between sources were bespoke and expensive to maintain. And merchants – the clients whose business decisions depended on understanding their own sales patterns – had no self-service interface of any kind.
The consequences compounded across three dimensions simultaneously: inconsistent data quality drove downstream errors in financial reporting and reconciliation; point-to-point integration costs made the platform slow to extend; and with no usable data product to offer merchants, a monetization channel already built into the commercial model remained entirely unrealised.
The problem wasn’t technical capability. It was architectural intent: a platform built to process transactions, not to create value from them.
The Approach
Most implementation partners would have layered analytics on top. Apexon replatformed instead.
The conventional response to a data siloing problem is to add a reporting layer – build connectors to existing systems, deploy a BI tool, and declare the data “accessible.” This pattern is fast to propose and easy to scope. It is also slow to deliver on: it preserves the underlying fragility, turns every new business requirement into a new integration obligation, and surfaces data quality problems downstream where they’re most expensive to fix. A competent vendor could have proposed it and been given the work.
Apexon identified the flaw in that logic before scoping began. The real barrier wasn’t connectivity – it was that the platform had no concept of a data product. Without that, any analytics layer would only be as trustworthy as the ungoverned data beneath it. So the engagement started from a different premise: rearchitect the platform for monetization, not for throughput.
The foundation was a unified data architecture on Azure and Databricks, ingesting from multiple source systems and converting raw transaction flows into governed, monetizable outputs. At its center was Apexon’s iC4 framework – a production-ready approach to data quality that let business teams define rules, run automated checks, and catch anomalies at ingestion, before they could propagate. Merchants gained self-service dashboards with direct visibility into their own transaction performance and spend patterns, requiring no engineering involvement to use.
On that governed foundation, Apexon built an Agentic AI consumption layer: a conversational interface allowing SMB merchants to query their data in natural language, access demand sensing signals, and optimize trade spend. What had been passive data exhaust became a billable, differentiated service layer – new commercial value built on infrastructure the client already owned.
What Changed
The platform stopped moving money and started moving understanding.
The most significant shift wasn’t operational – it was commercial. Merchants who had no visibility into their own transaction behavior now have direct access to category-level SMB insights, shopper spend analysis, and promotion optimization through a conversational interface requiring no technical expertise. For the client, this is a fundamental expansion of what the platform is: not infrastructure, but an intelligence service that merchants pay for.
Internally, data quality issues are now caught at ingestion rather than discovered in reconciliation. The architecture was built to extend – new workflows onboard without rebuilding from scratch, which means the economics of growth improve at every step. And the platform now runs at full production scale: 12,000+ transactions per second across 2 million pay points, with 2.5 TB processed daily through automated quality and governance pipelines – no manual intervention required.
Outcomes
Merchant intelligence monetized ↑
Transaction data converted from operational exhaust into a billable, differentiated service layer – new commercial value on existing infrastructure
Zero rework ↑
Data quality caught at ingestion via iC4 – before it reaches reporting, reconciliation, or compliance workflows
12,000+ tx/sec ↓
Real-time ingestion from 2 million merchant pay points at full production scale
2.5 TB/day
Processed through automated quality, governance, and aggregation pipelines – no manual intervention
PLATFORM DECISIONS
Data product over data pipe. Rearchitected for monetizable outputs, not faster movement. Throughput without usability isn’t an asset.
Quality at ingestion, not at reporting. iC4 catches anomalies at source. Fixing errors downstream is ten times more expensive than preventing them upstream.
Agentic consumption over static dashboards. A conversational interface serves the full diversity of SMB merchant needs – not just the questions a dashboard was designed to answer.
Why these choices, not the obvious ones
Why rearchitect rather than integrate the existing system?
A connector layer would have been faster to scope and easier to sell. It also would have left every fragility in place – each new business requirement becoming a new integration, each data quality problem surfacing late and expensively. Siloed architectures don’t become unified through connectors; they become more expensive to maintain. The only way to build a platform capable of generating merchant-facing data products was to start from a foundation designed for that purpose.
Why govern the data before building the product?
Analytics tools surface whatever data they’re pointed at. A BI layer over ungoverned data produces dashboards that look authoritative and aren’t – and users who learn, quietly, not to trust the numbers. Governance built at the data layer, with defined quality rules and automated observability at ingestion, means the product itself is reliable. A merchant self-service interface only works if merchants trust what they’re seeing. That trust is built at the foundation, not the front end.
Why a conversational interface rather than dashboards?
Dashboard design requires predicting every question a merchant might ask – and building a view for each one. At SMB scale, those needs vary enormously by business type, category, and season. A conversational interface lets merchants ask the questions they actually have, not the ones the dashboard was designed to answer. And every query refines the system’s understanding of what merchants actually need to know – compounding value with use rather than decaying with it.
The broader implication
Financial technology companies are sitting on data assets they’re not monetizing. The gap isn’t volume – it’s architecture.
The payment data already exists. The merchant relationships already exist. What most fintech platforms are missing is an architecture that treats data as a product rather than a byproduct – governed at ingestion, structured for extensibility, surfaced through intelligence interfaces that create direct commercial value. Organizations that solve this systematically don’t just reduce operational costs. They expand what their platform is.