What reconciling 100 billion transactions taught about trusting AI in production

Wole Olorunleke, VP of Finance Systems at Moniepoint, published a piece about what he learned building the systems that reconcile more than 100 billion transactions for the fintech in Nigeria and the UK. The central thesis: the reliability of an AI system in production doesn't come from the model, it comes from the governance of the data underneath it. The piece originated from a panel at the AI Everything MEA event, in Cairo, where he was the only operator among investors and a journalist.

The angle matters to those building software in Brazil for a concrete reason: fintechs, digital banks and any product running credit scoring, churn prediction or fraud analysis on transactional data face exactly the problem described, with or without generative AI involved.

The 'active user' problem that breaks the model

The example that opens the piece is the most instructive. At a financial institution, the system automatically debits the SMS fee at the start of the month and credits interest for the period (if conditions are met). These are transactions generated by the system itself: the customer didn't open the app, didn't transfer, didn't buy anything.

If the definition of 'monthly active user' (MAU) is 'any customer with at least one transaction', these dormant customers show up as active. The result, according to Olorunleke:

• Marketing reports high MAU to the board.
• Product sees low engagement, because average ticket size drops when real actives are mixed with dormant ones.
• Finance sees a third scenario, since it tracks revenue-generating activity, and neither transaction generates any.

Three teams. The same underlying data. Three different stories.

The point that matters for AI: if you train churn, credit scoring or personalization on top of this data, the model inherits the confusion. It treats a dormant customer with an SMS debit as if they transacted every day. In the author's words, "it's not a model problem. The model is doing exactly what you told it to do. It's a governance problem."

Governance born of constraint, not strategy

The most useful part of the piece is that Moniepoint didn't design governance out of foresight, but out of operational limitation. In Nigeria, according to the author, most banks don't have APIs capable of supporting the volume the fintech processes, so statements had to be manually uploaded into the reconciliation system.

This creates an immediate trust problem: if whoever uploads the statement is also the one who approves it, there's no verification. The solution was a maker-checker system, in which whoever uploads can't be the one who approves. From there, the principle spread across the entire architecture.

The concept underpinning the rest is the full chain of custody for each transaction. When the system reconciles automatically, it records not just the match, but which pipeline made the decision, with what logic, and who built that pipeline. If a data engineer created the tagging logic and it classified a transaction a certain way, you can trace it back: this result exists because of this pipeline, built by this person, with this logic.

It's this design, born from infrastructure precariousness, that today coincides with what regulators demand in AI governance, traceability and human oversight.

Why the conversational layer only works with governance underneath

Another concrete example: when the finance team grew, the default solution was 'everyone learns SQL'. It worked for a while, and then it became the same MAU problem multiplied, ten analysts writing queries with slightly different logic against the same data and arriving at slightly different numbers. Finance professionals became tactical, spending hours on joins and figuring out which of three tables had the correct revenue, instead of strategic.

The answer wasn't to teach SQL to more people, but to build a layer where the data is already governed and defined. On top of that, a conversational interface where someone asks "what's this month's revenue by entity?" in natural language and gets a reliable answer. The author is emphatic:

Governance is not a feature of AI. Governance is what makes AI possible. Without it, a conversational interface is just a chatbot writing bad SQL faster.

The 'operator's audit': three questions to test governance

The most useful part for anyone evaluating (or building) an AI system on top of data is the three questions Olorunleke proposes, with the warning to ignore the pitch deck and the accuracy benchmark:

| Test | The question | Warning sign | |---|---|---| | Triangulation | Show the same metric (revenue or MAU) across three dashboards: Finance, Product and Board | If the numbers diverge and the team spends ten minutes explaining why the logic is different, it's a 'truth problem', not an AI problem | | Semantics | Who owns the definition of 'active user' or 'revenue'? | If the answer is 'it depends' or 'everyone kind of knows', there's no governance, there are 'data opinions', and AI trained on opinion is a hallucination engine at high speed | | Post-mortem | Tell the last time your data was wrong. How did you catch it, and what was the chain of custody for the fix? | Whoever says 'our data is never wrong' either hasn't really scaled or isn't looking |

The author admits that Moniepoint itself hasn't finished the journey: AI capabilities were born in silos (the Finance Systems team among the first), they work in production and process real money, but they don't compose with each other. Now comes the harder work, centralizing definitions and standards into a corporate data framework. The phrase he said on the panel: "most companies sell Phase 3 while living in Phase 1. We're firmly in Phase 2: building the foundation."

The community didn't buy the narrative

The Hacker News thread was mostly skeptical, which is worth noting as a counterpoint (it's reader opinion, not verified fact).

Much of the reaction attacked form before content, starting with the site's custom scroll. In the thread, marcwieserdev was direct: "I loaded the site, saw the scroll, closed the page. I won't read your content, you have no credibility to my eyes because of your horrible UX."

The most substantive criticism came from oefrha, who questioned the technical coherence of the traceability argument:

AI writing aggregate SQL queries ("what is this month's revenue by entity?") is completely reliable because every tx is traceable, but wouldn't be reliable if every tx is not traceable, seriously?

>

-- oefrha

Not everyone dismissed the thesis. pjc50 found the argument valid: "The underlying thesis is interesting too as a financial pitch to increase traceability. Some subtle digs at the .. less honest methodologies sometimes used in front of investors."

What this means for the Brazilian developer

Setting aside the noise about the page design, the core of the piece survives a practical takeaway: before plugging any model on top of transactional data, it's worth running the 'triangulation test' internally and checking whether three areas arrive at the same number from the same source. A scoring or anti-fraud pipeline that inherits conflicting definitions of 'active', 'revenue' or 'customer' doesn't have a model problem, it has a data problem, and no amount of tuning fixes that.

What remains open is exactly what the community called out: the deterministic traceability described (recording the pipeline, logic and author of each match) is good data engineering, but it isn't exclusive to AI, nor does it prove, on its own, that the models built on top of it are trustworthy. It's a necessary condition, not a sufficient one.