Why your AI brain needs clean books first
On a recent episode of the Fintech Garden podcast, our founder Dumitru Condrea joined host Igor Tomych to talk about something that sounds obvious until you try to build it: banks are moving from showing customers what happened with their money to helping them understand what is going to happen next (Fintech Garden, episode 172, "Banks Are Getting AI Brains"). Budgeting copilots, spend forecasts, cash flow nudges. It is a real shift, and it is coming to corporate treasury faster than most operations teams expect.
But the episode made one point that gets skipped in almost every AI pitch deck: none of that forecasting works if the underlying accounting is a mess. Igor put it plainly. If you cannot cleanly separate cash flow from profit and loss, you are building your AI layer on a swamp, not solid ground. A $120 annual subscription paid today is not a $120 loss for the month. It is $10 a month for twelve months. Get that wrong at scale, across accounts and currencies, and every downstream prediction inherits the error.
For a fintech operating in more than one currency, that swamp has a name: reconciliation.
Matched is not the same as posted. A transaction can be correctly matched between a bank statement and your ledger and still be booked wrong in the P&L.
The part nobody puts in the pitch
Most vendors selling "automated multi-currency reconciliation" describe it as a software feature. It is not. It is three separate problems stacked on top of each other, and skipping the order gets expensive.
The first problem is access. Under PSD2 (Directive (EU) 2015/2366), pulling bank statements programmatically across multiple institutions requires Account Information Service Provider status. That means registration with a national competent authority before a single line of matching logic gets written. EBA Guidelines (EBA/GL/2017/09) set the bar: business model, security policy, governance, professional indemnity insurance. This is a licensing decision, not a technical one, and it belongs at the start of the project, not somewhere in a Phase 3 retrospective.
The second problem is format. Some banks have moved to ISO 20022 camt.053, a structured, currency-coded statement format maintained through SWIFT. Plenty have not. Legacy MT940 and MT942 messages are still common, and the currency or reference data often sits buried in unstructured narrative text inside the `:86:` field. Any reconciliation engine built against one format and pointed at the other will silently fail or, worse, silently misparse. A canonical internal schema with separate adapters for each format, validated against ISO 4217 currency codes before anything downstream touches the data, is not optional engineering hygiene. It is the difference between a system that works and one that looks like it works until an auditor asks a hard question.
The third problem is the one Igor was really describing on the podcast: accounting correctness. IAS 21 requires foreign currency transactions to be recorded at the spot rate on the transaction date, monetary items to be retranslated at the closing rate at each reporting date, and exchange differences to be posted separately to profit and loss. That is a precise, auditable rule. A reconciliation tool that matches a payment to a bank line and calls the job done has not actually closed the loop. It has to get the rate binding right, classify monetary versus non-monetary items correctly, and post the FX gain or loss on its own line. Skip that and your books are matched but not correct, which is a worse trap than an obvious error because nobody notices until year end.
The 90-day problem that breaks "fully automated"
Here is the detail that trips up almost every team that promises zero-touch reconciliation forever: the RTS on Strong Customer Authentication (Commission Delegated Regulation (EU) 2018/389) requires periodic SCA re-authentication on a roughly 90-day cycle, even where a fallback access path exists. In practice, that means a customer or an operations team has to re-consent to the data connection on a recurring basis. If your product roadmap or your client's expectations assume permanent, invisible automation, this is the regulatory reality that will interrupt it on a schedule you do not control. Build the re-consent flow into the product from day one. Do not discover it in a support ticket.
Where this connects back to the AI conversation
Put these two threads together and the lesson from episode 172 gets sharper. An AI layer that forecasts spending, flags budget risks, or recommends where to cut costs is only as good as the ledger underneath it. If the reconciliation feeding that ledger has not cleared the licensing gate, cannot parse half the bank formats it receives, or posts FX differences incorrectly, the AI brain is making confident predictions on top of bad data. That is worse than no automation at all, because a wrong forecast delivered with confidence gets acted on.
The sequencing matters. Compliance access first, then format normalization, then accounting correctness. Only once those three layers are solid does it make sense to add a matching engine, and even there the right architecture is deterministic matching first, fuzzy matching second, with any LLM-assisted triage confined to a human-reviewed exception queue. No large language model should be the system of record for an auto-posted accounting entry. That is not caution for its own sake. It is where the actual liability sits if something goes wrong.
What this means for an operations lead reading this in September
If you are scoping a multi-currency reconciliation build, or evaluating a vendor who says it is "fully automated," ask three questions before you ask about pricing. Do they hold, or work through, a licensed AISP registration for the markets you operate in? Do they handle both ISO 20022 and legacy MT940 natively, or only the modern format? And can they show you, concretely, how FX gains and losses get posted under IAS 21, not just how transactions get matched.
None of this is glamorous. It will not make a good demo slide. But it is the concrete under the building Igor described on the podcast, and it is the difference between an AI assistant that genuinely helps a finance team plan ahead and one that produces confident, wrong answers faster than a human ever could.
If you want to talk through how this applies to your own reconciliation stack or AI roadmap, get in touch with the Novafin team.