Improving personal financial health through non-predatory, transparent fintech.
I’ve worked with Bits on and off for over 7 years. I co-founded it back in 2019. Bits started from the basic problem in predatory finance which is - credit scores are discriminatory and entirely broken. They enable the inherent biases that exist in banking and global finance, and they compound massively on the bottom 50% of the financial customer base.
Bits set out to solve this by enabling consumers by improving their personal financial reporting, with the aim to create a habit forming environment of self-improvement through education. If finance purposefully makes it self opaque through jargon and arcane process, Bits provides the clarity that can deliver empowerment.
Bits is called Bits because initially, as an early stage YC startup, there was no capital to handle debt. To build - for example - a basic credit builder credit card, you have to accept the losses, even if the loss limit is $10. Compound that at scale, and you have a large required debt facility. As an early stage fintech, securing a debt facility is impossible. And securing even early credit models is very difficult - to build a model you have to lend, to lend you have to take on risk, to take on risk you need facility. So to lend someone $10, Bits needed to secure $5 (or a ratio that was suitably de-risked). This meant to get a bit of money you had to give a bit of money, and the ratio of that money lent was directly tied to your behavioural markers. Give a Bit, get a Bit. Bits.
But this debt conundrum is one reason why a lot of early stage fintech comes from large traditional lender incubators. Even securing a $5 deposit requires regulation and licensing, and at time the UK was seeing a boom in Neo-banking (Monzo, Starling, Wise), which was causing severe backlogs and shocks in regulatory support. This was a major problem. We just didn’t have the weight of investment to fast-track and secure the required institutional support.
But a secondary problem remained - traditional lenders need new borrowers. To acquire those new borrowers, they need to derisk them. If you cannot derisk them at scale, you focus instead on the upward mobility of your existing borrowers. If you provide a product to those lenders which provides them potential new borrowers, those borrowers have to meet their lending criteria. But that criteria is reliant on traditional credit and behavioural markers, specifically those that are easily modelled through traditional, automated KYC processes - identity, earnings, expenses, assets, debts. You cannot adhere your own behavioural markers - even if proven to be derisked - as a proxy for the traditional KYC markers. There has to be - at some point - a reckoning between the ambient risk profile and the KYC markers.
I co-founded Bits to solve the problems of opacity, accessibility and narrow risk criteria. It did not directly resolve these problems, but it remains very successful. Here I’ll go through some of the product and strategy that I applied to Bits over my tenure, specifically the failed experiments which were designed to refactor and reposition Bits into a different, more diverse market. Why the need for diversity? The nature of the finance industry forces any product handling the bottom 50% of the customer base to gain the classification of ‘sub-prime’. Sub-prime is a difficult label to wear if you want to raise debt. So while a sub-prime product can be very successful, it ultimately has a ceiling. To bypass that ceiling you’re forced to move towards more prime product offerings.
Early experimentation.
Give a bit get a bit. Early movements into secured lending were hampered by a lack of debt facility, which was primarily undermined by a lack of credit model and quant. This was later resolved as we build a quant model based on lending input, but to gain that lending input we realized early on that we would need a subscription model to underpin any lending model. A regular subscription payment provides effectively a pseudo-deposit, but also proves as an early marker to both behavioural commitment and cashflow. If your subscription fails, then likely your cashflow is poor.
I spent considerable early research time determining - or trying to determine - how a complimentary lending model could be built with few traditional credit markers. One promising early model was based on the concept of Net Worth - that a customer may have net worth in their community or family group that could constitute wealth in other terms. Really this was about trying to generate a trust metric that could be either applied to a financial decision or could be leveraged in some way to discourage default.
At Pollen I spend a lot of my time trying to quantify what ‘fandom’ is. What makes a true ‘fan’. Because fandom generates a sliding scale of trust markers. Are they a fan because they have 25 ticket stubs for gigs attended? Are they more of a fan because they have all their artists albums on vinyl? Are they less of a fan because their personal social output is fan-like, but their financial situation prevents them spending on merch? Bits was asking the same question, but it was asking it in terms of risk - is someone who subscribes to Netflix more or less likely to default on their monthly payment? Is someone who has a large community presence more or less likely to run up uncontrolled debt? And if so, was it the community pressure that applied that behaviour?
Later experimentation.
With a credit builder Mastercard, Bits passed the $1M ARR figure, through, at the time, high yield Meta conversions. This funnel is now all but dead, and Bits was very fortunate to ride that funnel to solid operating profits. But with $1M ARR it opened up our quantitive baselines.
We knew banks wanted borrowers. At the time rates were low and money was cheap. The funnels for traditional lenders - including at that time AMEX - were as wide open as any prior time. I began working on trying to build enterprise funnels into the traditional sector, which at the time I called Genesis. Genesis was conceived because at that time in Bits, we had a very good Quant who I was working with who had been inside the Bank of Scotland Credit teams. The insights from there led me to create an early credit risk API which could be integrated into traditional KYC lending flows.
Bits users at this time were able to lend - say $10 - on a $10 subscription, but had to pay it back each week. Lending that $10 at some retailers meant in reality $12 or some variant, depending on the retailer discount. This meant that a Bits user was generating 4x the quant that a standard acquired user at Capital One was at the time. We leveraged that to create a early signals acquisition funnel, that focused on the top 5% of Bits users who had enough time to build a reliable credit profile with weekly paybacks, which we could move upstream to the traditional lenders.
This product got a lot of early traction with Capital One and AMEX, but ultimately Bits decided to kill it and focus instead on Consumer acquisition.
With a focus on Consumer acquisition and retention, we ran early tests on Investments, Coins, Reward Tokens and Rewards. What was clear at this stage however was that the true retention lever was Card limits. Running research groups with users it became very clear that users wanted a clear path to increased limits over time - when their limit will increase, by how much and what they had to do to achieve it. For any Card-based product this presents something of a quandary. If retention is muted by a lack of limit increases, but the credit model cannot support that limit increase, nor can the debt facility, what is the retention solution?
Designing and executing a credit limit increase pattern, even an algorithmic one is a solved problem. The issue becomes less about increasing the limit and more about decreasing liability.
Creating linear paths to limit increases with boilerplate rules and checkpoints did solve the underlying problem of perceived progression in the user groups. It did not solve the exact timeline for the increases, but to do so would equally endanger retention - if a user truly sees the timeline for their progression and that timeline is not within their expectation, it becomes impossible to manage the expectation and that user will churn. I experimented with timelines, transaction feeds and credit limit reward feeds.
The most promising was assigning credit limit based directly on usage behaviour. If you boil down the users card transactions into a singular feed, and inject that feed with education, nudges and attainment goals, then you create a timeline that can be expectation managed more easily. It has the addition benefit of being able to handle rewards as a retention vehicle - because the timeline is more conversational, quiet periods can be filled with attainment goals, side-quests and aspirational nudges. This in turn increases interaction, and with interaction comes, typically, lower risk.
Placing this less as a ‘credit card’ environment, and more as an activity feed, you gain the added benefit of being able to change the conversation from statements and limits to a rolling progressive state.
Early testing on this was promising and it felt conversational. In particular it made the statement feel like an active discussion, rather than a table on a PDF. I felt strongly that this approach would scale well - that the timeline could leverage interaction well, and that as a surface it provided real depth to the machinations of the product sat below it.
I also felt that this natural progression in statement handling was ‘obvious’. Which in finance is a good thing. It’s established enough to be trusted, but it’s progressive enough for competitor products to feel old and outdated. Pretty much the sweet spot.
Ultimately Bits decided to move into multi-turn chat environments, and the timeline was shelved.
Agentic approaches.
AI in consumer finance has something of a trust issue associated with it. While apps like CLEO were early adopters of chat-based interaction, at the time most AI-based applications were chosen on first-time download. That is to say - I as a user will choose an AI approach to my finance knowledge vs I as a user of a statement-based app will adopt the AI features you supply me.
The obvious solution then was to build an AI-based app separate to the main Bits app and over time manage the merge if traction proved the feature. There are some immediate shortcomings with AI in finance applications, and they are very important to consider.
If the AI is expected to review traditional lender-based data, that data will not be categorized correctly, and most likely the codes one bank uses are not aligned with another. This means that the app has to in some way reconcile these disparities.
If the AI is expected to project or compile (such as “Show me how much I spent on X this week”) then you have to consider how this data is stored and tagged, and that it is tagged correctly. The simplest way to achieve this is human-in-the-loop reconciliation, but the flip-side of this is that in a pure reconciliation environment, the user may have to categorize a spread of 100+ transactions to get an agentic accuracy of above 90%. This is not a happy path.
If the AI is expected to converse in real time about transactions, those reconciled transactions may still force hallucinations. When Claude talks of ‘I might make mistakes’, in financial education those mistakes may have very bad implications. In an application where you have ‘absolute truth’ (such as a credit card balance), the associated ‘AI truth’ has to be managed carefully. If the credit balance clearly communicates a payment of $10 is due today, but the AI suggests otherwise, which is the truth the customer believes, and which is defensible?
If the AI is expected to review transactions in ‘real time’, the bank API pull time becomes critical. If the data is delayed or the API token revoked, the AI will try to handle the error state, but you will not be able to control how the AI does it. Additionally, ‘real time’ has the risk of poorly managed expectations - I am conversing in real time and getting real answers, why is the data not real time. Too often I’ve seen the ‘blame’ placed on the application layer and not the API by the user (for obvious reasons).
If the AI hallucinates, the user must have a means to reject the response - or better yet - review the receipts on that response to determine the truth of it. This is an early stage critical trust marker, and very useful in QA.
If an entirely semantic agentic platform is created and it relies on the individualized banking connections (eg via Plaid) to generate a response (eg, ‘How much am I spending on food this month’) - you have to consider firstly what constitutes food and month, but also what constitutes food for this specific user, their specific spending behaviour, their specific bank codes, what they have connected and do not have connected and the mis-aligned time codes per connection. These can be resolved through IFTTT rule-setting for the most part, but the issue becomes one of quality - for each user, filtered through the assigned IFTTT rules, the outcome is different, and therefore, QA, conceptually in the traditional sense, becomes impossible.
The best approach I’ve found in Agentic Fintech is to provide measured human-in-the-loop breakpoints which feel natural and not forced labour. This is a nuanced decision of where to place them in the flow, and ideally they are piggy-backed on other core app functions such as notifications or systematic admin loops.
This is a checks-and-balances model. It’s high friction - partially on purpose (given the need to stop the user to consider nuances, reaffirm truth, concede untruth, reapply knowledge, proceed) and partially because of the default nature of the agentic environment. The default UX position here is to attempt to remove all friction possible, but doing so opens up a chasm of trust, which compounds over time. Say, for example, you categorize Uber as food and not transit. Uber can be food and transit. Perhaps in this geo-territory or banking code system the Uber Eats and Uber Rides is not differentiated. Any question related to Uber spend will be incorrect. The solution in this scenario is to apply friction to the user to force the delineation of the two Uber spends - which is a highly cognitive process which invokes memory recall and the review of historical behaviour. This from a UX point of view is a negative, but if you can build a feature where the the customer benefits from understanding their historical behaviour, and the cognitive effort is rewarded, then the friction applied becomes ‘good’ - the customer benefits, the AI benefits and the application is seen as more trusted.
Of course the Uber example is highly simplified. Banking has much more nuanced problems. One of the biggest problems is transfers, and it undermines most agentic offerings. In a transfer, you the customer are sending money to someone else - or perhaps yourself. $1000 is moved from one account to another - that other account is often nameless or coded (depending on the bank or process), especially in some e-payment environments. This is one problem. The bigger problem is the lack of intent. If I as a customer spend $1000 at an Airline, this is travel. Either I have bought a flight, a seat, wifi, lounge access, a meal - but ultimately my intent in my spending is Travel. So if I then ask an agent ‘How much did I spend on Travel this month’, it’s a clearly tagged transaction, and the answer I’m given should contain that $1000. With transfers, this is not so clear. If I transfer $1000 to a friend to pay for the group travel, then my answer will not contain that $1000. But transfers have bigger conflicts that affect the larger living costs of people. Many people who rent apartments transfer their rent amounts directly or indirectly to the landlord. Those who share apartments or live together will routinely transfer their share of food, utilities and rent. Given that the majority of agentic users will routinely ask about living expenses as their early prompt interactions, transfers quickly become an issue in generating a sense of high-impact cashflows in the majority of customers.
So the solution becomes a decision based on friction. Do you force the customer to reconcile all their transactions and tag them (highly cognitive, involves clear historical transaction mapping and flows orientated around simple ‘bucketing’). Or do you, at the other extreme, tell the user that the agent is simply non-complete and unreliable? At a higher-level you really need to ask - is the agentic deep knowledge of the transactions actually solving a user problem? Or is the agentic approach primarily a ‘smarts’ exercise (i.e look how smart our app is!). Often the ‘smarts’ being the result of forced user labour is not a great trade-off unless you can directly point to traction or a specific use case, and this is something that typically gets forgotten on the sunk-cost fallacy that tends to grip any team that is 4 months into understanding transaction complexity.
The danger of open world.
If you provide a user with a chat interface, much like Claude, and present it to them with their bank accounts integrated, generally speaking they will not know what to ask. This is pretty well known as the Google Home Page Problem, which is a shortcut way of saying - sometimes you want to browse, sometimes you want to ask. If you want an overview, or just want to ‘check on things’, a semantic feed is next to useless. To try to offset this issue I began playing with prompt generation as a single touch target, with the aim to surface useful prompts in a dismissible state - type and it vanishes, pause and it appears. A simple way to try to get around the cognitive load problem.
My issue with this however is - this is very DAU-coded. It’s not passive, and it feels like it trying to force the interaction in an environment where there is no financial benefit to the interaction, and the worse-case outcome is unnecessary token burn.
I expanded this into Voice to see if voice would cause less confusion, but voice presented a more complex business case than we had appetite for at the time. Token burn with voice was exponentially larger than text, and the multi-turn energy in voice forces that exponential cost higher than a text based interaction.
Neo-investment.
On a parallel path, I built out a complete investment platform based on the design system I”d implemented - but an investment platform routed in absolute simplicity. The platform allowed you to play with real or imaginary money and understand at your own pace how investment worked. This was seen as a bridge between casual structured investment (eg, Savings, Pensions) and amateur investment at scale (Robinhood).
This tested very well but to scale the brokerage-as-a-service environment involved US incorporation and the eventual business model was entirely limited to US-brokeraged trade. There wasn’t the appetite for this at the time, but it was a great process of building an entire investment architecture that could scale.
What now?
Bits continues to build it’s business (or ‘book’ as we call it) in London, UK. It continues to be successful, and hopefully it can chart its path to diversification over the coming years.