I have been consulting with fintech startups for most of my career, mostly on the data and backend side. Neobank products, credit tools, personal finance apps, lending infrastructure. One pattern showed up so often across these engagements that I eventually stopped treating it as coincidence and started treating it as a fact about how the industry works.
Almost every team building a finance app for consumers ends up spending four to eight weeks building the same thing: a system that takes raw bank transaction strings and turns them into something a user can understand. Merchant name cleaning. Category assignment. Cashflow aggregation. The names and implementations varied, but the underlying problem was identical across dozens of teams I watched tackle it independently.
Each team re-solved it from scratch. Some did it well. Most did it adequately. All of them spent engineering time on it that they would rather have spent on the actual differentiated thing their product was trying to do.
That observation is why I started Openaggr in Tampa in early 2024. The transaction intelligence layer is necessary infrastructure for any finance app that shows users their spending. It is also not a source of competitive differentiation for most of the teams building it. The neobank's differentiation is its community, its fee model, its design, its specific user segment. The category taxonomy and the merchant normalizer are not where that differentiation lives. So why is every team building it?
The Specific Problem We Solve
The problem is the raw transaction description string. This is what banks actually send you when you connect to their data feed via an open banking API or an account aggregation provider. It looks like this:
AMZN*MKTP US AMZ4829K
WHOLEFDS MKT #00297 AUSTINTX
SQ *BLUE BOTTLE COFFEE SF CA 12042024
UBER* EATS 8005928996 CA
ACH DEBIT 231381100 TFR 882920A
PAYPAL *INSTAGRAM CA 4029357733These strings are not designed for end users. They are artifacts of the payment processing chain: truncated merchant names, processor codes, acquirer IDs, terminal location data, and various internal reference numbers. The same merchant can appear under dozens of different string representations depending on which bank, which card network, and which payment terminal was involved.
To show a user their spending breakdown, you need to answer three questions for each transaction: who is the merchant, what category does this spending belong to, and how does it fit into their broader cashflow pattern. None of those answers are in the raw description string. They require a layer of processing, a data model, and a classification system that has seen enough examples to generalize.
We built that layer. We maintain a category taxonomy with over 1,200 merchant subcategories. We run a classification pipeline that resolves raw strings to structured merchant records and assigns category codes with confidence scores. We provide a cashflow aggregation engine that builds on top of categorized transactions. And we expose all of it as an API that a developer can integrate in an afternoon.
What We Are Not Trying to Do
Openaggr is not a banking license. We do not hold funds, issue cards, or provide regulated financial services. We do not want to be a banking-as-a-service platform. We are not building a consumer app. We are not trying to be Plaid or MX in terms of open banking connectivity. We are the intelligence layer that sits downstream of connectivity, not the connectivity itself.
We also are not trying to serve every type of organization that touches transaction data. Enterprise accounting software, corporate spend management, institutional trading infrastructure: those involve transaction data but different problems than the ones we solve. Our target is the team building a consumer-facing finance product that needs to show users their spending in human-readable form. Neobanks, PFM apps, budgeting tools, financial wellness products. That is the problem space we understand and the one we are built for.
We are not saying that building transaction intelligence in-house is wrong. Teams with specific user populations, unusual spending patterns, or a genuine differentiation strategy built around category quality should own that layer. Our point is that for most teams, that is not the differentiation they are after, and the build cost is higher than it looks.
Why We Started in Tampa
Honest answer: I live here and I had been working remotely for the preceding few years anyway. Tampa has grown meaningfully as a technology hub, particularly in the financial services space given the concentration of banks and financial services firms headquartered in and around the region. There is a real community of fintech builders here that I have been part of for several years.
The geography is not the interesting part of the story. The interesting part is that being close to financial services organizations gave me repeated exposure to the same build-it-in-house problem that I eventually decided was worth solving at the infrastructure level. That exposure came from conversations and consulting work across a range of growing financial technology teams, not from a single dramatic insight.
The Three People Building This
We are three people right now. I focus on the business side, customer relationships, and product direction. Yusuf Adesanya, our lead engineer, has spent his career building data pipelines and classification systems; he is the reason our enrichment pipeline actually works at the quality level we aim for. Adaeze Mensah joined as head of product because she spent several years on the consumer product side of PFM apps and has a very specific perspective on what categorization quality actually means to an end user versus what it means to an engineer.
That combination matters. Transaction enrichment as an engineering problem and transaction enrichment as a product problem look very different. Yusuf can build a system that achieves high accuracy on a benchmark dataset. Adaeze can tell you whether the errors that system makes are the ones that actually damage user trust in a real app, or whether they are errors users never notice. Both perspectives are necessary for building something that works in production, not just in an evaluation harness.
Where We Are and Where We Are Going
We launched the Openaggr API in early 2025 with the core enrichment endpoint. Since launch, we have added the cashflow forecasting endpoint, the recurring detection API, the merchant enrichment response fields (canonical name, MCC code, category), and the split transaction detection feature that identifies when a single purchase appears as multiple charges in a transaction feed.
We have been building this from our own revenue, which means we make decisions based on what developers actually use and what they tell us does not work, not based on what looks impressive in a slide deck. That pacing creates some constraints, but it also creates a product that reflects real integration requirements rather than theoretical ones.
The roadmap items we are most focused on: custom category taxonomy support for Scale tier clients who serve specialized user populations, improved handling of international transaction strings as more of our customers operate outside the US, and better confidence calibration at the long tail of merchant coverage.
If you are building a consumer finance product and have reached the point in your build where you are staring at a database full of raw transaction strings and wondering how to turn them into something useful, that is exactly the moment this API was designed for. The sandbox is free, no card required, and you can have a working integration returning enriched transactions within a few hours.
We built this layer so that you can spend your engineering time on the part of your product that only you can build.