Archive · Fintech
CSV Parsing Bank Statements
A way to import CSV bank statements when open banking APIs like Yapily and Plaid could not reach the bank, or could not reach far enough back.
This is earlier work, kept here because people still find it. Olively today is an AI product consultancy — if that is what you are after, start with the AI Reality Check or the readiness scorecard.
The problem
What the work was actually for.
Two problems sat underneath the same feature. Many banks had no reliable API connection, which meant tax reports, investment insights, transaction history, balance sheets and portfolio analysis simply did not work for those customers.
And where an API did connect, it often returned only a short window of history. Financial insight built on three months of data is not insight. Users needed a way to fill the gap themselves.
Uploading a statement sounds trivial until you look at what a bank actually exports. Every institution formats dates, amounts and columns differently, and a wrong guess corrupts the numbers a person is about to make decisions on.
The outcome
What actually changed.
Around 2,000 CSV formats were handled by launch. Customers whose banks had no API connection, and those whose API returned only three months of history, could finally use the tax reports, portfolio analysis and balance sheets that the product was sold on.
The decisions
Three calls that shaped it.
Define the data rules with engineering before designing anything
A workshop with the backend team first, to establish what could be accepted and what had to come from the user. In a parsing flow, the constraints are the design.
Make each step explain itself
Cognitive load matters most where a wrong answer corrupts data silently. Every step in the flow states what it is asking for and why, rather than assuming the user knows what a date format is.
Test with expatriates specifically
They were the users most dependent on the feature, because their banks were the ones with no API connection. Testing with the general user base would have missed the cases that mattered.
What was hard
Date formats were the hard part. Every bank exports them differently, and a wrong guess corrupts a tax report months later without anyone noticing. That is why the rules were agreed with the whole team before any of it was designed.
The hard part
The hard part was date formats. Ask the wrong question and a database discrepancy quietly corrupts someone's tax report months later. That meant defining rules and limits with the whole team before any of it was designed, rather than discovering them in production.
The work
What it looked like.
Technical constraints
A workshop with engineering first, to establish what the backend could actually accept and which data had to come from the user to keep the numbers trustworthy.
Information architecture and user flows
The flow had to explain itself at each step. Cognitive load matters most in the part of a process where a wrong answer corrupts data silently.
UI design
Tested with expatriates specifically, because they were the users most dependent on the feature and the most likely to hold accounts at banks with no API.
Mapping the columns
The hard part. Every bank exports dates and amounts differently, and a wrong guess here corrupts a tax report months later without anyone noticing.
What I do now
Most AI projects are theatre. I help you build the ones that aren’t.
An AI Reality Check scores every idea on your roadmap and hands back three lists — what is real, what is theatre, and what is blocked. One week, fixed price.