When you’re at the start of something there are so many questions; are you working on the right problem? Is the problem valuable? To whom? Even if it is a valuable problem, will your solution be right? Will it even be good? Is there more than one right solution? Are you asking the right questions? Do you have the right inputs? Etc

To get around this, we often rely on prior art set by our predecessors; I call these defaults. Using defaults allows you to limit the number of variables you have to affect, or the number you’re trying to test or can afford to adjust in this round. In product or company development these will be the APIs or heuristics/assumptions that generally have worked before and are well documented. For example, if you’re building a consumer stock trading product, you can build the functionality on Alpaca and DriveWealth’s APIs, who have abstracted away the regulatory + technical interface for various exchanges like the NYSE and NASDAQ, instead of going directly to the exchanges. You can rely on Google Adwords for initial acquisition instead of building a new acquisition channel from scratch. You’d treat these as defaults and apply your creativity to the variable you’re exploiting (e.g. free options trading or prediction markets, whatever that is).

However, the tradeoff is that when you rely on prior art, you adopt prior constraints. This means living on top of technical decisions that preceded you, economic structures that were put in place before you, by different people with different incentives and payoffs, when different things were technically or regulatory possible. This limits the kinds of breakthroughs and inventions available to you.

Breakthroughs = Original + useful

One of the hardest things to do in product development is consistently building things that are both original and useful. The diagram that’s been in my head for a long time is:

The way to read it is:

• When building a new product, you start in the center. The interior of the circle is explored territory, including everything that’s been tried.

• Most of the people with that problem today are already solving it somehow. They might not love that “how”. But they’re doing it. Those are the orange spots within the circle. They’re sparse because most attempts don’t result in something useful.

• Breakthrough products require exiting the circle (building something original) AND landing on an orange spot outside it (that original product being actually more useful than what exists today). Most unexplored territory is just as barren as explored territory.[5]

To build something original (without regard to whether it’s useful), you just have to exit the circle. Build literally anything that hasn’t been built before, regardless of utility. An example of this is Humane[6]; they built something that hadn’t been built before and was thoroughly original. It just ultimately didn’t beat existing alternatives on utility (or beat them sufficiently enough to reach escape velocity).

It’s also easy to build something useful; just copy what already exists (any of the orange spots inside the circle).

To get to a breakthrough you can imagine 2 paths

1. Conviction based, single shot

2. Iteration based, multi shot

To build something that breaks through enough that customers change their current habits in a single shot with no iteration, is incredibly difficult. You have to have conviction that what you’re building hasn’t been built before (so it’s outside the circle), and also solves a problem so much better than existing alternatives, that customers see it and switch fast enough to pay off the (often) enormous initial investment.

I don’t have a good frame for this (hitting the target in one shot) . I’ve seen it referred to as “taste”[1] in the past, and I have shipped a couple of products this way, but it’s emotionally and financially expensive to change so many variables thoughtfully, last long enough to synthesize and ship, AND last long enough to survive if you are wrong. This is why so many (including me) fall back to iteration all the time. I assume that most first shots will miss, and most of the time customers wont care about what I ship first. I focus instead on building the discipline and muscle to keep shipping original things quickly, with each subsequent iteration refining my intuition, reflecting my learning from past iterations, and increasing the odds we get there.

This way, you don’t get attached to a solution - you start with an opinion, and every subsequent iteration reflects that opinion seasoned by your learnings from the last iteration. Theoretically over time you should get closer and closer to the target. And simply because you’re trying and you’re out there, you’re learning and refining your understanding of the problem. Seeing what is useful is easier from the new point of originality (When users are trying and not liking your product, you’re out selling and it’s not resonating etc) than it is from your starting point in the middle of the circle.

Everything is a variable

The best way I’ve found to synthesize this is “Everything is a variable”, if you have enough:

• Horizon or time scale; if you can sustain your effort for long enough, you can position yourself for something unorthodox that doesn’t yet exist, and wait long enough for the world to come to you

• Resources: with enough money, you can turn knobs that others would consider frivolous, or economically incent others to change for you

• Intent:. Think of this like persuasion or coercion or charisma or the “reality distortion field”; basically the combination of things that results in someone making what would otherwise be considered an irrational or suboptimal decision, on your behalf. [4]

What I mean by “a variable” is anything you can directly change. I’ve spent years working on complex systems in financial services and healthcare, and almost every time I peek behind the curtain, I realize I’m working with someone else’s defaults.

Viewed through this lens, everything but natural laws/laws of physics can be changed. In software this includes; language, database model, open source primitives, behavior paradigms, feedback loops, marketing, sales approach, and can even extend to things like partnerships and supply chain. The most original thing you can do is to change 100% of variables. This is super hard and has a high risk of wasting effort, because the existence of useful products is evidence that some percentage of existing variables are already toggled to the right settings to solve some user problems.

Artistry is understanding which variables, when changed, will have the highest differential impact on user/customer adoption (getting people to try it), behavior (retaining those people) and outcomes (delivering the utility for them)[2]. Leverage can be unlocking new (non-exhaustive list):

• Utility: do something that couldn’t be done before

• Lower cost: sustainably deliver the same outcomes for less cost

• Speed: deliver the same outcomes faster

• Precision: deliver higher quality outcomes

• Aesthetic: create beauty, surprise or delight along an axis users care about

Changing more variables makes your product more original and compounds leverage if they all end up mattering to users. The risk is that only some matter but you spent resources to change all of them, thus reducing your return on investment. Applying massive change to a single variable can also be effective if you pick the right one.

How this came about

I first made this observation building the Cash Card in 2015. We designed a card a user would sign when opening an account, and tried working with several card manufacturers to bring it to life. We struck out for a while - it took almost 2 years to launch. In that time period we cycled through 5 banks, 6 card issuers and 7 factories across 5 card manufacturers. We took novel positions on everything from how it would be made, shipped, marketed, its regulatory positioning, the features customers would have, and how money would flow.

For example, the prevailing default card manufacturing & personalization method was foil tips (pressing foil in the shape of the design you wanted, onto the card with some heat application). The first drafts we got were super unsatisfactory, and our initial partners pretty much refused to try anything beyond off the shelf techniques, which drove underwhelming results.

Laser engraving (which we eventually shipped) was only used on a limited set of premium cards at the time (Chase Sapphire and Capital One Venture and JPM Platinum - all cases where the card stock was metal) and hadn’t been used the way we intended (as art). To launch, we changed a ton of variables from the defaults, initially focused on aesthetic leverage:

• experimented with over 300 configurations of card construction, finish, overlays, laser positioning, angle, resolution, depth, intensity, and more. Initially, we didn’t even know these settings existed. It was only after several factory tours that this became clear.

• Experimented with hundreds of paper, envelope, print and finishes for the carrier which optimized for everything from aesthetics to ensuring the QR code would print in the right resolution to ensuring the printer at the card manufacturer wouldn’t jam when running at high speed

• Collaborated with our card personalization partner to procure new equipment so they could support our use case (remember at this time, no one believed the Cash Card would be huge - Square was sexy and Cash App had basically no name recognition).

• Required our personalization partners to change their shipping pickups from 1 per day to 3 per day (and eventually settling at 2/day)

The variables we changed include; the plastic, the personalization, the paper, the envelope, the card activation, setting a PIN the design, the logistics etc (and this is only considering variables we changed in the physical world). We treated every single attribute of the product as a variable, and went unreasonably deep to explore the spectrum of settings we could turn each variable to (I’d have photos of this but we weren’t allowed phones/cameras on the factory floor, so you’ll just have to believe me).

We ended up catching a huge wave as the Cash Card took off and is now a massively scaled with over $1b in annual profit, but it’s rare that you get such a win in one shot (and in reality we started with loose product market fit, and iterated our way to tighter and tighter product market fit over the years by improving it’s usefulness. In this case, at the start, we used both horizon and intent; from when we started prototyping the Cash Card to when we shipped it took 2 years and we waited to get it right. The card manufacturers didn’t do what we needed because we paid them extra; it took a deep amount of engagement, belief, and persuasion to get them to do something unusual. We didn’t use resources - Cash App was extremely financially constrained at the time, so we couldn’t just pay partners or vendors to do what we wanted. They took risk and invested capital based on our vision & potential, not guaranteed returns.

One core risk with changing many variables at once; prior art/prior abstractions also are easy interfaces to other organizations. The more variables you change, the more expensive for you and your ecosystem to get things done. Suppliers and partners have preset ways to work with them. Sometimes a variable you want to change is in a partner’s control, and it’s not economically rational for one (or multiple partners to change in a synchronized way. The cost is more than just money; it’s opportunity cost they forgo by implementing your roadmap, and the risk that even after all that it might not work out, and they’ll be stuck having made an investment with no payoff. To do this, we had to find partners who had deep incentives to break from the norm (I only realized in hindsight that part of the reason our card partners leaned in was because they viewed it as a way to win market share if things worked out). In addition - we needed what I describe as “intent”; the combination of factors that resulted in them adopting this change with no guarantee they’d be directly compensated.

The second time I observed this effect was when we wanted even more original outcomes and went direct to materials providers to explore novel constructions of plastics, glass and metals. Many of these innovations eventually made it into consumers hands, and were possible because we now had scale. Iterating materials is an expensive process that would produce expensive, premium outputs. We had sufficient resources (to afford the upfront process) and scale (to manufacture enough that the cost was reasonable and have confidence we could distribute the outputs).

I saw the same pattern play out a few times at Carbon, and I’m now seeing the same pattern play out again at Substrate (which prompted me to try and codify my thinking here). We’re trying to build something that is both novel and useful - an AI native product that actually executes RCM tasks on behalf of a practice, and owns the outcomes of that task (in contrast to hybrid approaches where you hire or acquire an RCM operation or a team of humans, and try to automate away the humans in the loop)

It’s novel because no one has succeeded at scale before doing what we do. The largest and most successful companies in RCM are hybrid services providers like R1 RCM and BPOs like Cognizant with tens of thousands of employees. These companies are insanely successful, have huge scale and massive onshore and offshore labor footprints. It’s useful because providers, practices, health systems and BPOs unequivocally want these outcomes and already spend heavily to achieve them. Doing them with technology only (vs. hybrid) means changing a LOT of variables, but can yield leverage in cost, speed, consistency, auditability and more, if we’re successful.

The pivotal question for us is: is it possible to deliver the business and operational outcomes healthcare providers already pay for, with technology alone? By the way - if you’re interested in this problem, we’re hiring.

Tesla is an example of applying massive change to almost every variable - they also make cars, but everything about them is different from the supply chain to the existence of self driving. [3]

Massive change of many variables requires a long horizon, a lot of money and a massive amount of intent. Tesla embodies all 3.

Bringing it together

I wrote previously about Wave Hunting; how choosing to work on valuable problems is a force multiplier on execution. Even after you select a high quality problem to solve, it’s possible to miss macro shifts (technology adoption curves, regulatory changes, economic structure shifts) that multiply the returns on shifting certain variables in that problem space. Revisiting the Cash App example, the Durbin amendment capped interchange, but also it:

• changed which customers banks could profitably serve, which

• Reduced competition in certain acquisition channels, and

• Made it possible to build a whole generation of financial products targeting those consumers (Cash App, Chime, Robinhood, Dave and many more all benefited deeply from this)

Wave hunting is about how the problems you choose to solve often drown how well you solve them. Thinking of everything as a variable is a reminder that once you’re focused on a problem, many things that people take for granted as fixed, can in fact be changed. Breakthrough products often require both.

Thanks to Nico Chinot for reading this in draft.

–

[1] Iteration and conviction based approaches are not inherently in conflict, they just have different tradeoffs. In both, you need to independently have an opinion/belief about how the world will be different from what came before. What differs is how much resources you risk. In iteration based approaches you inherently risk less in each round, but the potential payoff from a single round is relatively low, so you have to compound iterations over time. In conviction based approaches you basically can risk all your resources in a single round. If you’re right, the payoff is immense, but if you’re wrong, you don’t get more rounds.

[2] Just because everything can be changed, doesn’t mean everything should be. Trying to change everything can also be a sign of analysis paralysis, again because it’s just not likely that the best outcome available can only be achieved by changing every single variable.

[3] Unlike my other examples I’ve never worked at Tesla, so this example reflects my observations from the outside looking in.

[4] The narrowest way I can think of to describe this is persuasion - creating a suite of arguments so effective that the counterparty is convinced to do something that they would not have considered rational prior to the argument. The broadest is the “Reality Distortion Field” concept which is almost adjacent to religion; using some combination of factors to get large numbers of dispersed actors to buy into your cause and coordinate on your behalf.

[5] there’s a kind of breakthrough product that relies mostly on a marketing or branding innovation where what you’re doing is changing how people think or what people believe without really much change to the substance or utility of the product. I recognize these exist and I can’t really speak on them because I don’t understand them.

[6] This is not a knock on Humane. Building that product in that category takes a ton of courage. Breakthroughs are hard and most don’t work.

I started writing because I ran out of people to talk to about banking (seriously). I’d spent years deep in ledgers, card issuing and reconciliation, and no one I knew wanted to talk about Durbin, tradeoffs between financial reconciliation models, banking partners etc.

Writing has helped me meet people thinking about similar problems, from whom I’ve learned a ton. I’m hopeful it will also help me meet people to work with.

We’ve been building Substrate for almost 2 years. As with many new ideas, there’s a period when you’re walking through the maze, and the way out is not clear. Then there’s a period when you can see all the way through. We’re at a point where I can see several ways through, and we’re now hiring to pick the right one(s) and run at them as fast as we can. Our primary constraint is execution.

What we’re building

We’re attacking a massive problem in an opinionated way:

• We’re helping doctors get fairly compensated for care they’ve delivered.

• I’ve lived what it was like when this doesn’t happen. I’m building Substrate to fix that.

• Healthcare RCM is a massive market. Most players solve problems by throwing bodies at them.

• There are lots of companies you can invest in or join where the model is to either merge with or hire a big outsourced team. Many have raised lots of money, and are growing fast. I applaud them, but that’s not what we’re doing.

• We’re doing the opposite - trying to solve every part of the problem using software & agents. Some examples of what we’re building and the problems they solve:

  • A claim status agent that does the first step of AR Follow Up

  • A policy agent that checks if a payer would consider an encounter medically necessary (before you do a prior auth)

  • Appeals automations that submit medical records requests and attachments to payers

  • Payment reconciliation automations that post exceptions like payer clawbacks, balance patient credits, issue refunds and more

• After all the growth, everyone has to answer the same question: can you actually get software to do these tasks? Can software do these tasks better than humans? We’re answering that question first. We’re front-loading the “eat your vegetables” phase of our development, and we already have material proof that it’s working.

If you’ve ever read my writing and wondered what it would be like to work together, or there’s someone in your world who you think would enjoy it, now’s the chance.

My hiring philosophy

Throughout my career, I’ve leaned hard into hiring mispriced talent, because I’m that. I plan to do that this time too. What do I mean by mispriced? I mean generally that you’re capable of having insane impact, but you’re shaped in a way that employers often don’t know what to do with you. Examples*:

• Unreasonably obsessed: if you enjoy going endlessly down the rabbit hole trying to fix problems once you sink your teeth into them, lets chat.

• Ex founders or founders in transition; you’ve started a company before, and you’re not ready for your next one, but you’re still hunting for a mission. (this also applies if you haven’t started a company before but plan to, or you’re a founding engineer somewhere)

• T-Shaped: broadly strong but unreasonably deep on one dimension (often so deep that you know very few peers with as much applied knowledge as you)

• Career boomerangs: you’ve been out of the workforce for a while, often for personal reasons, and you’re ready to grind, but bigcos will ask you to “explain this gap in your resume” before they politely decline

I deployed this philosophy for over a decade at Carbon and Cash App with spectacular results. In addition to being massively impactful, many alums have gone on to start companies or run teams in their next adventures, going after really big, hairy, ambitious problems. A few examples:

• Alex Cohen, founder/ceo at HelloPatient

• Kalie Dove Maguire, president at Evidently

• Levent Bas, founder/ceo at Altira

• Henrik Berggren, cpo at Mutiny

• Noah Manders, founder at Bsyde

• Maurice Chiang, vp product at Spring Health

There will be more. They could be you.

What I’m looking for

Everyone has buzzwords that they use to describe the people they like to work with. Here are mine.

• Load-bearing: outcomes would be worse if you weren’t present. Fahm spent weeks at Dodger’s stadium mid pandemic, checking in patients in person to ensure a tight feedback loop on the vaccine infrastructure we were building.

• High Urgency: you’re a self kindling fire, and always want everything to go faster

• High Agency: every problem is your problem. Kalie saw patients at Carbon clinics while building the EHR, and built a coding copilot that collapsed both clinical and financial friction.

• Curious: you value understanding over winning arguments, and you’ll get as close to the metal as necessary in service of it. Ashu spent weeks with materials producers to learn how card plastics were mixed and come up with truly unique card combinations.

• Dissenters: it’s your duty to tell me I’m wrong, and call out when things don’t make sense. Henrik called bullshit, in public on terrible product org decisions I’d made, long before I was willing to admit them.

I genuinely believe one of the best ways to get to know someone is to be in the trenches with them and embrace the tension that comes with two disagreements. This will be no different.

What’s in it for you

• We’re no bullshit and low ego, and recruiting primarily in person, in San Francisco. My goal is to build a small, tight knit team that is more than the sum of its parts.

• You’ll go unreasonably deep on systemic, real world problems in healthcare, both at a technical and business level. Everything from reading EDI companion guides, medical necessity policies & healthcare payment regulations to using all that insight in service of processing every single transaction the right way.

• And if we’re successful, doctors get paid fairly!

• Whatever you do after this, I’ll move mountains to help. My knowledge and network are yours.

• The maze metaphor is real: there are several ways through, but the one(s) we pick depends on who is in the room. You’ll influence that.

• (Eventually) swag you’ll love wearing.

Conversely, if you want a clear roadmap or a lot of direction, this isn’t for you. Among other things, we’re hiring for judgement. Even if you don’t fit cleanly into any of these buckets - if you’re in engineering or GTM and interested in healthcare and RCM, please reach out.

We’re hiring for engineering (sample roles here and here) and GTM.

If this is you: email kunle [at] substrate [dot] cc with a couple of bullets on why this is you, and a github/linkedin/resume. Even if you’re not ready for a change today, please reach out. I can be patient.

If you know someone: Send them this post, and why you thought of them.

If there’s someone I should meet: even if they’re not looking, email me their name and why. I’ll reach out thoughtfully.

I wrote previously that synthesis is a new bottleneck because I observed my production capacity, expanding as I adopted coding agents[5] for more and more tasks.

This is based on my experience, dramatically expanding my own capacity, understanding that something new is happening and trending, and trying to grapple with the implications. I’ve read some pushback basically saying “if you’re so productive what did you actually ship”. The critics have a point, but miss one as well. Some personal examples are below.

Lots of what I spend time doing is making good decisions and applying judgement. In this context shipping more stuff to customers is one kind of victory. Improving the quality of decisions (inputs) is another (quite valuable) kind of victory. A lot of what coding agents have helped me do is get to more decisions more quickly and in a lot of case better decisions that I have higher conviction in earlier than I would otherwise.

You can execute a task without understanding it; you can press the button you’re told to press, and so can a computer. The process of synthesis: understanding what a thing is, why, the implications and second order effects, the decision that needs to be made; someone needs to do that. Someone needs to be accountable for it, be correct, take responsibility when it doesn’t work, and place it in the context of the organization or mission you’re executing upon.

When you own outcomes, better decision making is insanely valuable. When you’re trying to build something at all,, to build something differentiated, compelling, that breaks through and be responsible for a success or failure - you live and die by decision quality. If people using coding agents never shipped a new feature to customers (unlikely) but all made even 5% better (or faster) decisions, that is a humongous amount of leverage being created. [3]

Coding agents are for everyone

I used to think of coding agents as a tool for coders/developers/engineers. I now think coding agents are tools for everyone. Every human and every organization has some set of things they want to do where they’re operating at the edge of the software available to them. Coding agents make it possible to either do really customized, niche specific things, or extend the software to a niche or custom or emergent use case.

I’m still trying to articulate the types of tasks that I’ve been finding success with. I haven’t yet explored everything that’s possible, and it’s also likely that the exact shape/parameters of the tasks that are legible to this approach is rapidly changing and expanding.

The best way I can think to describe it is -if a task can be done entirely on a computer, it’s probably legible to a coding agent. If you have a task that is tedious and repetitive and, and the data used in each repetition and the clicks used to perform each repetition are fairly uniform, that task is probably legible to a coding agent . Tasks that used to require technical expertise are far more doable to a coding agent assisted non-technical person. This doesn’t replace most technical people - think of how much time you spend saying “no” as an engineer. Coding agents enable the non-technical people asking the questions, to ignore the “no” and try it for themselves. And that is good![1]

An App for Every Task

So far, my general approach has been

• Describe the problem. This can be very low fidelity; more detail is better, but a single line can often be enough to start

• Rely on the planning agent to shape the idea and extract precision

One challenge I see here is to date, most of my interactions with planning agents haven’t extended beyond 4 or 5 questions. I suspect that if the gap between your starting point and a sufficient answer requires more than four or five questions to gain precision, your outcomes will be less optimal or take longer. More specificity is better upfront, but don’t let thorough be the enemy of getting started.

Second, I’ve begun to think of my use cases in terms of apps. Anytime I have a task to do. I describe the outcome I want, and ask it to build an app or a dashboard that lets me

• Track what’s being built

• Once built, track what’s being done

• Validate the task meets success criteria

This approach enriches the feedback I give in the session. Viewed through this lens, every time I’m doing a task. I’m also building an app to QA the task and the output.

A few tactical examples:

1. Finders: I’ve built several tools that will search the Internet for a common type of artifact for a common type of entity that’s not centralized. These could be things like EDI companion guides, medical necessity policies, regulatory language on a specific topic and so on. I aggregate these for analysis in a later step (usually also assisted by a coding agent).

2. Structure Extraction: Taking a large corpus of PDFs from a variety of sources, extracting common values and comparing them for analysis. For example, comparing the medical necessity criteria amongst different payers and plans, or comparing state regulations affecting patient billing and reimbursement. 2 different payers (or 2 different plans from the same payer) might require different prior treatment before authorizing a specific procedure - cutting agents provide a way to scale that discovery.

3. VLOOKUP on steroids: my most frequently used function in google sheets is VLOOKUP. It’s great if the keys in both data sets are structured and clean. If either is diverse or messy or they come from different systems of record, I can now easily create a python script to probabilistically find relationships, use examples to flesh out different matching strategies, and generate a UI to review the results, fix incorrect matches, observe errors and generally ensure the app is doing what I actually intended. In this context, the UI is deeply not important. What is important is the coding agent gives a visual interface to manipulate its output.

4. DIY API: in a lot of cases you have Zapier. But when you don’t or when you’re working with data that’s privileged in some way, you can have Claude code build you a translator. In my case, I’ll sometimes use a tool like granola to transcribe meetings and generate action items and I built myself a custom Apple shortcut automation that every day grabs all my action items out of granola and pushes them into my Apple notes, which is much closer to my system of record For tasks. Again, vanishingly simple if you’re an engineer, but completely opaque otherwise.

5. If there’s something you’re trying to do and the service you’re trying to do it with has an API you can have Claude code build the API integration for you to scale an activity you already do by hand, and give you a customized UI to yourself to interact with it. Brendan Keeler shared an example after my last post of something he built was Court listener:

   

Implications and opportunities

There are a ton of second order effects if you get mass market adoption of coding agents.

1. Browser w/Coding agent:I think there’s an opportunity for a new type of browser that is natively has a tooling like recording + coding agent specifically to build tools around repetitive tasks on behalf of users. This would be like a combination[2]

   1. Reasoning model that observes what you’re doing and tries to proactively make sense of it. There’s nothing really like this out there - I tried ChatGPT Atlas hoping for this and even agent mode doesn’t have something that assists you with automations.

   2. Planning agent that sketches out how to automate it and explores APIs/MCPs that could help

   3. Cloud infra to give your automations a stable home over time (like a combo of git + Vercel + Kernel[4])

2. Single task apps: We’re firmly in the era of throwaway single task apps. I’ve built and thrown away a dozen in the last month alone. I don’t think most of these will replace my SaaS usage, but maybe that’s just me. It’s currently so dramatically cheap to build an app that’s extremely custom to you, that just does one thing well (its literally been faster to do this than to brute force it, and in many cases with way better results)

3. Generative software: This is pretty hard to visualize but I think there is a concept of generative software that’s pretty interesting. I think of this like your SaaS that self molds to each specific users workflow so that the core remains the same and meets all your SLAs and things that need to be true and the interface molds itself around the user, gradually over time based on frequent usage patterns, support tickets and direct user requests (eg the user could specifically ask the software for a feature and get it right away. This is different from generative UI like Monogram [4] where the UI adapts to the task. This is more like the functionality molds around how the user works to extract the most usage out of them (imagine a world where addictive SaaS exists).

4. Self healing software: I think there’s also going to be something I call self healing software. This is where if you build something that generates results, you use a coding agents to not only improve those results, but to improve the software itself using this system’s data exhaust, your feedback etc. This is one of the paths we’re pushing on at Substrate.

5. Secrets Handling: I think we will see many more secrets leaked in the wild, and I think there’s an opportunity to create consistent secret handling tools so that anyone using a coding agent can have tools to safely handle secrets by default (instead of depending on users knowing what they’re doing bc they mostly don’t). Before the era of coding agents, I wrote about agent authentication problems. Mass adoption of coding agents expands the surface area and makes this even more acute; now not only can you leak passwords, you can leak API keys (which can often enable machines to exfiltrate more data faster, or spend down your credits).

6. Credentials: Related to handling secrets, a secondary thing I didn’t anticipate was how to safely handle credentials in the context of being able to turn every task into an app. In my case for example, when building something thats a browser automation, I ask it to include a 30 second wait at the start, so I can log in manually before enabling it to continue the remainder of the automation. Haven’t had to do this all that much, but extremely clunky.

7. The good APIs will win: Products (particularly systems of record) with good API coverage and documentation will probably extend themselves. This is because their users will be much more able to customize the system of record than previously was true at lower cost, and much more reliably. As a result, human users will be able to drive machine scale usage (along with the attendant spend, stickiness etc)

8. The consultants will be fine: In the short term, while this arbitrage exists, all manner of consultants are going to kill it because they’re going to appear far more impressive and become far more productive for their clients, simply because they incorporate coding agents into their workflow, while a client’s IT department spends multiple quarters debating whether to grant a ChatGPT license.

9. Maintenance & consistency; while its gotten a lot easier to build and output/throughput will increase, a lot of the overhead in software is maintenance and adaptation, patching etc, in addition to having a sense for what types of builds/code will be easy to maintain.

10. Measurement: this isn’t strictly a problem for coding agents. I think it’s true for all large language model powered products, but just understanding who in the organization is using these products, where they’re getting utility, what usage patterns are working, how much you’re spending, and whether the ROI is there is going to be really important. Larridin [4 is working on this problem, but today, the vast majority of companies are absolutely terrible at understanding how their employees are using large language model powered products. It won’t get better by itself.

11. Coding agents for non coders: all the coding agent tools are primarily accessible in IDEs (you can also access Claude Code via the Claude prompt interface). Most non engineers don’t know what an IDE is. Someone’s going to make a killing figuring out the right interaction paradigm for non engineers to access coding agents, including instructions, planning, QA, deployment, maintentance etc. In a way, if a non-code has to see code, the product is actually incomplete. Maybe its just Claude (with CoWork)?

Where this doesn’t work

Just observing my workflow the last few weeks I’ve found this dynamic most pronounced wherever I have something repetitive to do and each rep has >80% overlap in fields/values/clicks.

Whenever the substance of each repetition diverges, this breaks down. I recently had to create logins for hundreds of different websites and tried a few times building something to assist me. I just couldn’t get something done that would’ve been faster than doing each by hand. To date this is the only thing I’ve tried where I haven’t been able to get at least some lift from using a coding agent. Of course, there are a bunch of things that I do by hand because I want to or because they are not sufficiently repetitive that the payoff would be there. But to date almost everything I’ve tried to do (even things that I thought would be on the edge) that meet the above parameters have seen some kind of improvement. I read this as; as a non-engineer, I’m probably not good at telling what tasks would be susceptible to coding agent based approaches, so I should cast a wide net.

What this feels like

The two horizontal tools that basically every knowledge worker uses daily are

• A word processor (Google Docs or Microsoft Word), for qualitative work (eg communication)

• A spreadsheet (Excel or Google Sheets) for quantitative work (analysis & computation)

Analysis in the context of knowledge work means; you have some data, and you’re trying to make sense of it and understand what it means for a decision. Think of most times you’re in a dashboard and you hit “Export CSV”. The downstream task is usually some kind of analysis. Computation in this context means there’s a process you have to regularly execute, and the spreadsheet is the “rules engine” for that process. An example of this is month end close in accounting; a bunch of data is rolled up into some spreadsheets at the end of the month, and someone reviews by hand to make sure things look right and anomalies are accounted for, but the spreadsheets are doing the computation (it literally contains the formulas and relationships) and a human is reviewing them, rather than a human doing the computation themselves.

I mentioned before that spreadsheet work is “coding adjacent”; you need to be able to think logically, understand functions and formulas and how they relate to each other, you can build really complicated workflows in spreadsheets, and all this is possible without being a software engineer. But the reality is there’s probably as wide a distance between a beginner excel user and an expert, as there is between me and a 10x engineer (long before coding bootcamps were a thing, investment banks used to have excel bootcamps for incoming analysts).

I think being able to use a coding agent well will be similar to being able to use a spreadsheet well; horizontally required for all knowledge workers, to assist in the computation & analysis part of the job. Being good at it might not make you a 10x engineer, but will be a force multiplier vs. those who are not. In this way, I think the coding agent is the successor to Excel.

Thanks to Nikhil Krishnan and Jesse Wilson and Brandon Carl for reading in drafts.

[1] This is a double edged sword in a good way. As an engineer, you’re now gonna have to face some vibe coded prototype that completely elides a really good reason not to do something. On the other hand, as a non-engineer, it is now going to be super hard to justify why you showed up without a prototype. Not prototyping, not thinking through the questions, experience, edge cases and technical challenges is going to become a huge red flag. The bar is just . . . higher.

[2] the cursor browser tool is the inverse of this - it’s a coding agent with a browser stapled to it. Extremely useful for engineers, but from what I can tell not built to scale browser automations. I think the reverse will be just as useful for non-engineers.

[3] my point here is not that everyone will make better decisions. My point is that measuring productivity exclusively in terms of apps or features shipped misses a whole dimension of what it means to be productive.

[4] I’m involved in these companies either as an investor or advisor.

[5] So far I’ve tried Codex, Composer and Claude Code. Claude Code has been most impressive, but I assume over time they won’t be the only game in town. In addition, I think it’s pretty important to try new tools - the capability of these things is changing so much that I don’t think the existing interaction paradigms are the only ones that will work well.

—

Unrelated - I’m hiring at Substrate (www.substrateintelligence.com). If you’re load bearing and interested in working on thorny, deep in the stack problems, learn more here.

1. There’s a type of task that used to be extremely expensive to do, that has become dramatically cheaper. Many more people can do it than used to be true even six months ago, and most of them are not aware that they have the ability and as such, the value of this task is deeply mispriced

2. Because of #1, our capacity to produce is outstripping our ability to understand.

3. IDEs + coding agents accelerate #1 and #2.

While writing this I ran into this tweet:

This essay expands on what I think is happening from a non-engineer perspective,and some implications.

Task Arbitrage

I, like almost everyone I know, have unexpectedly experienced a handful of productivity breakthroughs over the last few months.

Most recently, some new habits I’ve adopted which prompted this realization:

• every night before bed I fire off a few tasks either in Claude code, conductor or cursor

• I every morning check on the tasks from yesterday, set up some new ones and go about my day

I’m not an engineer, yet this set of habits have dramatically expanded my productivity mostly in ways I didn’t expect. The experience has also yielded a few surprises.

The first surprise is, there are an increasing number of technical tasks that I didn’t previously consider as coding, but are really amenable to code based approaches. A lot of the time these are tasks I would have done in excel or google sheets, often by sampling. Now, I’m asking a coding agent to do it in natural language, reviewing the outputs and iterating. At a minimum this allows my sample size to be much larger. More frequently I get to the work faster because I can get to a working version of the actual task much more quickly than before.

A second related surprise is I’ve experienced the greatest leaps and productivity using coding agents in an IDE versus using a prompt interface.

The third surprise is more of a realization. It doesn’t feel like AI will kill SaaS for a lot of SaaS use cases, because shipping a SaaS product (or really any product) is not just functionality; it’s SLAs, support, maintenance, precision, polish etc. Instead AI (And coding agents in particular) enables software to exist that wouldn’t otherwise be built. These tasks may never be sold or turned into a company or a tool, or may be too personalized to the way a particular individual or company works. Far below the threshold for a company to exist, there exists a ton of tasks that software can now do, and its now cheap enough for a non-engineer to build with a coding agent to do the task for them and throw it away (yeah I had coding agents build me a bunch of stuff I only used once and never looked at again). Even in my case for a lot of tasks I spend time on, it would never make economic sense for a whole company to be built around it because they are either too speculative (the payoff is not clear) or too niche (even if the payoff is high, there’s not enough transactions or repeat activity to sustain a company). In addition, as a former PM, you can now validate a lot of assumptions before ever asking your engineers or designers to get involved.

Some examples:

1. Built an app that aggregates several different search strategies for finding the right healthcare payer entity, given only a payer name. This is inherently probabilistic, and we only know if it works if the payer actually successfully responds. As we test these we incorporate them into our core payer search.

2. Automated several QA tasks that I’d have otherwise done as a sampling process (literally checking individual examples by hand). My default now is to develop a script to check the dataset with a small sample size, then scale up once i have outputs I like. Setting this up takes about the same amount of time as checking a sample like I would have done manually, except now I can run it over the entire data set instead of eyeballing a few.

3. Built a classifier to help analyze long tail errors for payer EDI messages

4. Built an explorer that helped aggregate and analyze large volumes of payer PDFs

5. Built an app to aggregate my todos across different apps into Apple Notes

This combination of tasks are reasonably different from one another in terms of substance, the context you need to do them well, etc. I find the collapsing of context and the easy production of a V0 to be super compelling, and there are simply enough tasks that I just wouldn’t have gotten done before. And I’m just at the stage where I’m getting comfortable that some of these tasks can start to run continuously without much intervention. Overall it clear is that there is a type of task that used to be very expensive to complete and now is dramatically cheaper. In many of these cases, I just woudlnt have done the task. This arbitrage is not priced in yet.

Production Capacity > Synthesis

The other thing that’s clear that I’m not sure what to do with is; I find my actual production capacity to be much less constrained for a certain type of task and that definition/type expands every day.

And I find the hard thing to be: now you’ve completed all these tasks that are reasonably diverse in all these different parts of your workflow or your business; actually synthesizing them ( ie consolidating them to make leaps or understand the second order effects), is no longer straightforward.

By synthesis here I mean[2]

• You complete a task, have outcomes, and those outcomes have an effect on the outside world

• You observe those effects, and they either converge with your understanding of how the world should work, or diverge

• You incorporate that convergence/divergence into your understanding, and now have a new, improved understanding (or at least realize that your understanding is more broken than you realized)

• You form a new hypothesis, which leads to a new set of tasks (or an improved ranking of what you thought you had to do next)

• Crucially synthesis is not just blending all the threads together. It is also understanding the parts of the puzzle that are missing as you go along and realizing that you need to go seek them out. New understandings often raise new questions.

This process is so nuanced; it requires judgement, intuition, relating to context that might not be directly present in a task (like think of doing a specific task at your company and realizing something material about a corporate priority is incorrect ). Just super hard to imagine how you’d compress this in the way you can compress a task.[3]

In the old world you had some grunt work that you had to do. That grunt work took time, and as you spent time in the weeds and details, you were kind of continuously synthesizing what you’d learned over and over again. As a result, the amount of consolidation and synthesis you have to do at the end to really understand the implications of the work that you’ve done, was actually relatively little relative to the overall amount of time you needed to spend on the task.

But now certain categories of grunt work are going away (ie the time required to do them is shrinking), while the time for and process of continuous consolidation/synthesis has shrunk. It might even be possible that there’s detailed nuance and depth that’s now missing, that you only realize when you’re in the middle of doing it, but I haven’t gotten to that realization yet. So now what I find personally is that synthesizing all these threads and bringing them together to realize a novel thing is hard and scarce.

Imagine you had a bunch of grunt work that was blocking something downstream, and now you’ve automated it all away. Sometimes it’s enough to sit down for 30 and really think things through + consider it. Sometimes that process takes days + discussions because something new is possible to build and that thing is not super obvious, but you still need to ship the original thing that the grunt work was the foundation for. So you immediately go to shipping, and haven’t spent the time to understand the novel insight yet. You have a tactical win (you shipped way faster than you could before) but you don’t have as much time to understand what it means for your business, which is important and drives long term compounding.

Synthesis is the bottleneck simply because in the past your capacity to produce, and to synthesize, and to understand might not have been matched, but they remained in the same ZIP Code.[1] Now your capacity to produce has dramatically outstripped your capacity to synthesize, and as a consequence, we might be moving to a world where you have more results than understanding.

Voice, IDEs & Coding Agents

One other surprise [4] that I didn’t expect has been that voice has actually been pretty transformational. I can’t tell exactly why this is or the human psychology of it. It is often easier to just vocally describe something in natural language, than it is to type it out as a first pass. Following that, I often use a planning agent to ask a bunch of clarifying questions, which I can later use to refine. This combination helps solve the blank canvas problem; you can start iterating your output with a disorganized thought, which is much less effort than you could previously.

The tradeoff is, you don’t necessarily always get to the level of precision that you would get if you really sat down and thought about the task that you’re working on. But you can get to 80% precision, and that is surprisingly very effective, and often yields results that will help refine your path.

I mentioned earlier that I’ve been using IDEs & Coding Agents quite a lot. I think one of the ways in which we don’t appreciate what’s happening in market is that in the old world tools like VS Code really were tools for coders. In the current world, IDEs like cursor and conductor have become tools for anyone who does structured work. They make it easy to flexibly generate and manipulate structured data, relate it to unstructured data, aggregate new data sources quickly, and process large amounts of unstructured data quickly. If you’ve ever worked with people who are expert excel users like investment bankers, it’s clear that spreadsheet use has a lot of conceptual overlap with coding. Interacting with tabular data through a coding agent + IDE feels like being able to get insane throughput out of a spreadsheet without needing to be an s-tier excel jockey. I wouldn’t be surprised if the thing that replaces Excel (or even productivity suites like MS Office or Google Suite) is not another suite, but a coding agent + IDE instead as this dynamic becomes more pronounced because agents become more powerful, and more people realize what’s possible.

[1] I’m pretty convinced my experience can generalize because I don’t think any of the things I’ve learned are special - I just happened to try them and they happened to work better and faster and more effectively than I expected. So my assumption is many other people are experiencing this or will soon, and as a consequence many people are currently executing far below their capacity and don’t know it (and this gap expands every day).

[2] It’s possible that my capacity for synthesis will also expand over time. Just hasn’t happened yet, and not sure how to more rapidly read, think etc.

[3] Also if you happen to be thoughtful about how to get better at the process of synthesis, I’d love to chat or read whatever you’ve got.

[4] 2 other surprises/observations; first, the tool you use/interface really matters. I find I’m much more able to prototype and execute on browser scripting workflows in cursor than in something like conductor, but anything that doesnt require a browser is far easier to interact with claude code directly in conductor. Makes me suspect that being willing to retry in a new tool/IDE is going to be important. Second, the Cursor browser tool points to something I suspect is gonna happen this year, which is that there is a new prosumer/professional browser to be built with native claude code integration, and whoever wins it will win a new emerging user who is browsing for a semi professional reasons but can scale a real amount of volume because they can now build automations that weren’t possible before.

—

Unrelated - I’m hiring at Substrate. If you’re load bearing and interested in working on thorny, deep in the stack RCM problems, learn more here.

Writing this with a request - if you see any interesting people, companies, or reading material around this area, please send my way. Have talked to a few folks building here, but eager to learn more.

Few thoughts

1. I’ve long thought that the majority of stablecoin demand has first been about giving defi use cases a currency to settle in and second about giving non US individuals and companies access to USD, with the former driving velocity/turns and the latter driving money at rest.

2. Under the hood, all the benefits of speed, programmability and more, are not at all bounded to stablecoins being backed by dollars. As a result countries that experience these frictions in financial services (settlement delays, time constraints around liquidity, limits etc) can really benefit from the technology itself, vs the USD access tailwind

3. The additional regulatory clarity from MICA & GENIUS create blueprints for regulators around the world, and supports infrastructure for them to connect to.

4. The administrative volatility in the US probably makes the ground marginally more attractive for stables to exist

Use cases & open questions

A few use cases are emergent and I’m curious about

1. Liquidity & Settlement: making it easy to go fiat to onchain in local currency with instant settlement and 24/7/365 availability (lots of countries have a local instant rail like Brazil with Pix and India with UPI, but how that works in practice differs from rail to rail)

2. FX: enabling a fully realized onchain currency pair that sidesteps the fiat to USD[Insert Issuer Here] conversion

3. What are the local conditions that make a stablecoin make sense to build and reach scale in a particular country?

4. Is there room for a sovereign stablecoin if the country already has an instant rail? Are the presence of limits the constraint? Why would someone who lives there choose to hold the local currency in fiat vs. onchain? What advantages would need to exist.

5. What does the presence/absence of regulatory clarity do to the development of a sovereign stablecoin? Are the users primarily consumers, businesses, or institutional users?

6. Does yield get treated the same around the world? Do banks have the same fears around the world? What’s different and why?

Some of the things that are missing

The point of all the background and implications isn’t to say that these things will happen. It’s to outline that the future might have attributes which look extraordinarily different from the attributes we experience today, and it’s not clear that we’re prepared.

Whatever future arrives will require much legislative and policy change, from many governments, and the new/updated social contracts that come with that. But the technology and tools available - to companies, governments and consumers also need to change. I think that to date, the tools available for consumers are by far the most advanced and compelling. Services like Sling, Dolar, Littio, Parallax, Chipper, Plata, BiLira and others (including hyperscale incumbents like Binance & Coinbase) provide consumers as compelling experiences as what they have access to in fiat space, and consumers around the world have far more choices available to them than businesses or governments. I also think the general onchain and stablecoin specific infrastructure layer has really matured. Services like Conduit, HiFi, Checker, Fireblocks, Brale, Stripe/Bridge/Privy, Yellowcard and others enable developers, fintechs, payments providers and traditional financial institutions to interact onchain and around stables in increasingly rich ways. In contrast, the tools for governments and businesses dramatically lag. Here are a couple I think are missing :

Business Banking, completely onchain, targeted at SMBs globally

Technology enabled business banking with a focus on quality experiences for mainstream SMBs around the world, completely onchain. American SMBs already have access to incredibly rich modern banking experiences with companies like Mercury/Brex/Ramp. Europe similarly has Revolut. All these businesses are growing like a weed in fiat space.

Consumers around the world already have access to global digital wallets like Sling, and regional leaders like Dolar are already onchain. 

There’s not really an onchain equivalent for SMBs. By this I mean; a super high quality/high craft user experience, built for non crypto native users but utilizing blockchain technology. From what I can tell the core feature set includes

• High quality local onramps and offramps: remove the friction of moving in and out of their local currency

• Obviated wallet management (customers shouldn’t need to be an expert in wallets, signing etc to be able to do basic everyday tasks that any finance professional performs)

• Programmatic instruments & flows: 

  • make it easy to receive funds in your local currency that automatically converts into a stablecoin

  • Make it easy to initiate payments, payroll, transfers and invoices in your local currency (so that a business can transact locally in their currency with local counterparties without having to worry about conversion)

  • Make it easy to tradeoff between speed, cost etc for each use case

• Multicurrency virtual accounts: enabling a business to have local instrument aliases (eg Account + routing number for the US, Pix Alias for Brazil, IBAN for Europe etc) in all your countries of choice, & handling all the necessary KYC & reporting. This would allow a business to receive payments in the currency/choice of their sender, and control where and how they pay FX. Wise does a really good job of this for consumers in fiat space:

  

• For more crypto sophisticated customers, you can also enable them to choose which stablecoin they hold their treasury in, mint their own coins, and easily convert in and out of other stablecoins along the way. This should help 

  • obviate fear of counterparty risk around something happening to a particular stablecoin issuer

  • Enable customers to earn the treasury return even when their funds are fairly small scale

Companies like Meow and Dakota are a version of this, but very focused on customers who are already onchain. Otherwise I don’t see many examples of folks building this, but I can’t tell if this is because the concept of an SMB doesn’t exist elsewhere the way it does in the US (with such intense density) or because it does exist and the demand is not there or their needs are shaped differently, or local products in the “global south” countries are just exceptionally good. My current hypothesis is that the big local/regional consumer champions will expand into business accounts as well, and enable SMBs around the world to on-ramp, off-ramp, pay and invoice locally, and manage treasury in stables.

This can exist both as direct to business, or as a platform that local financial services providers can use (think of this as something like Fiserv or Q2, just focused on onchain B2B products). A lot of the tooling to build this exists already in services like Bridge, Privy & Brale - it’s just currently targeted at developers not businesses.

Medium & long duration savings instruments 

Most “savings” in stablecoins today are short term or on demand: neither the saver nor the provider or issuer are agreeing explicitly that the saver will hold funds for a fixed period of time. As a result, issuers have to manage their treasuries effectively as a demand deposit: the deposit holder can withdraw their money at any time, and has a reasonable perspective that the funds will be available when they do. 

Medium term savings instruments like certificates of deposit (which have a fixed rate and fixed term and a penalty for early liquidation) and long term savings instruments like retirement instruments, pensions and life insurance policies are far more susceptible to being inflated away, than short duration savings instruments like a checking or savings account. With the exception of what Meanwhile is doing, I have yet to see good onchain services enabling long duration saving. 

This can be both direct to consumer or as a platform that local insurers or retirement providers can utilize.

Interoperability/backwards compatibility

One “issue” with self dollarization is that even though you can now save in dollars, you still have to convert into local currency in order to use your money. Between when I started this essay and today, several platforms have launched global card issuing including Rain & Bridge/Stripe. These products make it possible for a cardholder who are saving in stablecoins to use existing point of sale infrastructure in their daily life, in their local currency with no additional friction. Cards make stablecoins backward compatible with the fiat world. This doesn’t solve *everything* but is a meaningful improvement over managing the last mile yourself.

Until you’re able to go the everyday last mile; paying your mortgage, utilities, invoices and other base layer financial needs, there will be more to do. 

Analytics infrastructure for tracking onchain flows

Services like Dune exist and make onchain data really accessible. Services like Chainalysis enable onchain forensics. What's the equivalent of call reports for stablecoin issuers[1]? If you’re a regulator in any country in the world, do you already have tools to know how much of your citizen’s wealth is onchain or in stables and model how that changes over time, in response to fiscal and monetary policy actions? 

This matters less if you believe most onchain behavior is purely speculative. If you believe consumers globally will adopt stablecoins as a way to have access to a stable currency, then as a policymaker you should really care about what the adoption curve in your country looks like, because it literally affects the quality of your policy actions.

In addition, the more of your citizen’s wealth is held in stablecoins, the more you should care about the safety and soundness of stablecoin issuers. At some scale, liquidity or solvency issues with a stablecoin issuer can manifest as a real problem for you/your citizens. [2]

Government Payments Infrastructure

If you think of analytics as a “read” function, that helps monetary policy makers make higher quality decisions, I’m less sure what the equivalent “write” function is. My guess is beyond analytics, monetary policy makers are going to need a slightly different policy toolkit that enables them to interact onchain, manage wallets, secure value, disburse funds, assess taxes & liens etc.

If you’re in a country that’s “self dollarizing”, there’s a business to be built to enable governments to take payment (for taxes, fees, penalties etc) onchain in the citizen’s choice of currency, and convert or store it in the government’s choice of instrument. This will probably be somewhat politically charged, but hard to imagine that making governments more responsive to citizens is a bad thing.

Governments who explore & embrace onchain tools will more quickly understand how onchain dynamics coexist with fiat, and adapt more quickly to discontinuous events.

Global, Realtime IntraFi

If you’ve ever used a banking product that offers FDIC insurance on over $250k of balances, it’s likely powered by a brokered deposit or “sweep” network like IntraFi. 

Your bank likes these networks because they enable the bank to take on a higher share of your wallet and offer FDIC insurance on more of it. The other banks in the network like it because they get to acquire deposits they can use in various ways. And bank customers like it because they get larger balances insured without opening/managing a ton of bank accounts.

The way Intrafi works today, there are a handful of opportunities globally that I don’t think have been true about the banking system before. First, IntraFi has 2 transfer windows a day (the last one at 3pm ET). In contrast, bank customers largely have access to real time rails and can withdraw funds using various tools around the clock. As a result there’s a mismatch between how fast a customer can withdraw funds, and how quickly their bank can withdraw and settle the deposits from the network. This isn’t a criticism of IntraFi - more a function of where we are on the adoption curve of real time payment rails broadly.

I think generally we’re now in an era (over the last decade) where deposit flight can happen faster than most liquidity cushions can respond (this is likely true for all entities that hold balances including banks, digital wallets and stablecoin issuers). 

If you built a brokered deposit network on real time rails (combining stablecoin rails with real time fiat rails like Pix, UPI, Fednow, RTP etc) it would go some way towards solving the problem of a bank experiencing a run being able to keep up with deposit flight on real time rails. Real time fiat rails enable banks to exchange value instantly with other banks domestically, and stablecoin rails enabling banks to exchange value instantly across borders. In an environment where value is exchanged via correspondent banking networks, banks couldn’t exchange value nearly fast enough to solve liquidity problems. Onchain also  this is way more possible. 

For this to work, a few more questions have to be solved: will financial regulators allow the financial institutions in their purview to extend credit across borders in crisis? Could banks that are highly dependent on brokered deposits for their deposit base be highly susceptible to financial contagion (if all banks in the network recall deposits, its essentially a bank run, but by other banks in the network? Ultimately it might be the case that real time payments constrain fractional reserve banking; basically instant, always on payments can ultimately overwhelm any amount of cushion faster than the bank or issuer can get liquidity. This will mean banks have to keep more capital on balance sheet/lend less, and probably means less credit extended overall. Time will tell. 

Global Deposit Insurance Company (GDIC)

Most consumers and businesses have some version of deposit insurance for their deposits in their local currency. If you live outside the US but hold your savings in stablecoins, whats the mechanism for recovering your assets when a stablecoin issuer goes insolvent?

Widespread consumer adoption of stablecoins will most likely require consumers around the world to believe that if something should happen to their issuer, there’s a way they get their money back. GENIUS takes a first step towards this

“Notwithstanding subsection (a), any claim of a person holding payment stablecoins, as defined in section 2 of the Guiding and Establishing National Innovation for U.S. Stablecoins of 2025, issued by a debtor shall have first priority over any other claim against the debtor under this title.”.”

But the FDIC’s reputation as a safeguard for depositors was built over decades of successfully recovering depositors funds after bank failures. We’re only at the beginning of that reputation building for the stablecoin industry.

There’s a lot to build here:

• Actuarial underwriting infrastructure; this entity will either have to be privately run, or underwritten by multiple governments, or some combination, as no single government will want to (or have the political support to) do this itself

• Onchain reporting infrastructure that enables clear understanding of who held what at the exact point of failure 

• Automated infrastructure for calculating what core underlying treasury assets remain

• Trustless infrastructure for returning them to the end user’s wallets programmatically 

If you’re building any of these (or exploring), I’d love to learn more.

[1] I learned while writing this that stablecoin issuers do have call reports. Unlike with banks, they’re private.

[2] Even though both stablecoin holdings (US TBills mostly) and FDIC insurance are in practice backed by the full faith and credit of the US Government, I’ve had enough conversations with large institutional stablecoin holders that indicate they don’t view the two as interchangeable (that they do assign some counterparty risk to the stablecoin issuers when managing their treasury). I can only imagine that governments will do the same. 

For Americans, Fiat >= Stables

For the use cases around money that most American consumers experience every day, along with the attributes that they care about, stablecoins are not yet better than fiat. I’ve long thought that to compete in money products you need to either move money faster, pay more yield, or enable lower cost. 

• Speed: most American consumers have access to instant (or near instant) payments on most of the transactions they do everyday, with the counterparties they frequently interact with. Between intra-bank payments, Zelle/Cash App/Venmo/Paypal, and fednow/RTP/same-day-ACH, and payment cards, for most of the transactions American consumers experience every day in 2025, speed is not an unsolved problem the way it was a decade ago. You might say that if 100% of Americans were on stables then they’d all have instant, but then that's true for all the other instant rails, so the statement does not mean much[2]

• Yield: American banks and fintechs already compete ferociously on yield. Fiat backed stablecoins all (today) earn yield in large part from buying “risk free” securities (ie US Treasuries). They literally can’t (sustainably) pay you more than that. Today (August 2025) you can get those 3.5% - 4% yields with a US checking account from several banks.

  

• Fees: this one’s a little harder to parse/compare but fiat transactions and accounts aren’t free but neither are stablecoins. Both fiat bank accounts, digital wallet providers and stablecoin issuers subsidize consumers to hold and transact funds in different ways, and in both realms it is possible for consumers to have a “free” experience. These experiences are funded in a variety of ways, and I don’t mean to discount this. I’m more just saying that most American consumers already have a way to get a “free” “checking” account and “free” money movement in and out of that checking account. 

• Loans: unsecured loans for American consumers are available at hilariously reasonable rates (by almost any measure both geographically and historically) and have been in fiat space for a long time (and much less plentiful elsewhere). Unsecured lending onchain is not really a thing.

If you’re a consumer in the US with access to a Chase bank account (which is most consumers), you have it pretty good. Could be better, but I can’t point to an onchain consumer financial instrument for consumers that’s so much better than Chase that the average Chase customer would switch. And for the customers Chase wants to keep? No chance. Chase moves trillions per day (this includes lots of different transaction types so it’s not all “payments”) across a wide range of transactions, and is insanely proficient at cross selling consumers. Whatever else you might say about them, they have to be pretty performant to do that well. If you’re building financial products targeting the average US consumer, Chase is who you’re competing with. And the other competitors both in the neobank/challenger bank space, and traditional incumbents, are all ferocious.

If you work in payments, in the US market, this dynamic is viscerally obvious. I think it’s at least part of why a lot of payments leaders dismissed/ignored stablecoins until relatively recently. But it made me blind to the possibilities. 

For everyone else, Stables > Fiat

If you’re American, as of today, the instruments and transactions available to you in the fiat world are just as good or better than onchain generally, or in stables specifically. This might change in future, but in mid 2025 it's definitely the case. For a large portion of the rest of the world, this dynamic is not true, and has not been for a long time. If you live in a country that has experienced inflation or currency volatility in your life time, stablecoins give you something that is better than most financial products your local banks offer to retail consumers. That thing is not yield, or transaction speed, or low fees; that thing is stability, in the form of dollars. That thing is assurance that your $100 will still be worth $100 in 2 weeks, and (at least for self custodied products)  it’s much harder to seize or freeze than your local bank account.

Most senior professionals working in payments in the United States, have never in their adult lives had to experience currency instability personally in their day to day. If you’ve lived pretty much anywhere in the US for the last 40 years, you’ve basically never had the exact same loaf of bread cost $5 today and then $10 two weeks later. Same is true for most staples/groceries. Americans (and Westerners to a slightly lesser extent) take currency stability for granted. But for many people in the world over the last two decades, inflation (or broadly volatility in the prices of every day goods) has been the default state, and stability is a feature you viscerally crave. Stablecoins give you access to . . stability. Stables introduce a benefit Americans (and to a slightly lesser extent, people living in western nations) take for granted, to the rest of the world. This is one reason I think the best way to describe what stable coins are today in particular (beyond being a settlement currency onchain) is a vector for exporting dollars. [3] 

For people living with currency instability that pierces through to volatility in the prices of goods, stablecoins literally increase their purchasing power. For Americans, stablecoins don’t.

Consumers are adopting stablecoins faster than enterprise

We launched the conference with the hypothesis that very soon companies like Apple (mainstream consumer brands that everyone knows) would adopt stablecoins in core enterprise workflows. But the reality is that the Fortune 100 is very well banked and for the most part stable coins are not better than the banking system they have access to. They generally have high quality banking relationships in the geos where they operate, sophisticated finance teams and access to the best rates (on deposits, fx or yield) from all their banks.

I came away from the conference understanding that I had missed a really core story which is: billions of humans have only ever used a volatile local currency [4] their entire lives, and now they can just get access to dollars in very small amounts for reasonable conversion rates without permission. For this group, stablecoins are insanely disruptive. I wrote about this years ago and I think I just didn’t realize how big it could get:

“In contrast, prior to the existence of cryptocurrency, it was (and still is) fairly common for wealthy individuals in poor countries to hold foreign currency (typically USD, GBP or EUR) as a mechanism for savings. As a treasury/FX trader, I used to think (and I still think) that a good heuristic for a country’s economic trajectory is to look at where the country’s rich put their wealth. Wherever wealth is exported (e.g. if the move when you get rich is to immediately buy New York or London real estate) is a signal that citizens are afraid of wealth seizure (either explicitly by confiscation, or implicitly by inflation). 

Governments [will] hate this because it creates natural selling pressure for their home currency, but a fiat-backed stablecoin pegged to the US Dollar or Euro (with real assets under management) that is permissionless and effectively beyond the ability of the government to stop you from buying, is simply a digital asset substitute for a real use case that exists. Before stablecoins, you had to buy dollars from a bank and keep it in a bank account (which has its merits) but the bank could also a) just refuse to sell them to you (which is what happened most of the time), b) charge you a ton of fees to buy or hold it or c) be forced by the government to convert at a fake exchange rate or limit how much you could buy or own. Even in today’s environment, if you’re in the US you should try going to your local Bank of America or logging into your Chase mobile app and try to buy some euros, and it will become blindingly obvious how unsupported this is.” 

For the largest companies in the world, stablecoins are mostly a minor improvement on working capital (especially given that in many currency pairs they are orders of magnitude less liquid than the corresponding fiat pair) [6]. In contrast, for consumers around the world, stablecoins solve a hair-on-fire problem. This has only really been true in the last couple of years, and will accelerate whenever a country experiences a currency crisis or bouts of inflation. Consequently, the adoption around the world will not be uniform. You already see examples of this happening at a small scale. In Nigeria during bouts of inflation over the last 3 years, stablecoin adoption accelerated:

Similarly, in Ukraine, in the first 3 months following the start of the war, crypto transfers expanded by around 30%:

I suspect that given the recent shift to a more multipolar trading environment[7], we’ll likely see more economic dislocations happen to countries around the world with fewer multilateral institutions to help backstop them. Those dislocations will see the usual top down flight to quality as foreign investors pull out, and might also see a new bottoms up flight to quality as local savers flee to the relative safety of USD (via stablecoins).

The main reason I missed that consumers would lead the way is because establishment consensus typically comes from mainstream brand adoption. Your grandmother knows Apple, so if you said to her that Apple was using stablecoins to do something (literally anything), she would just assume it was serious/real. The secondary reason is that most of this infrastructure has been funded by vice, and (I’m not yet a super deep student of history) I can’t think of many cases where infrastructure built basically to enable speculation is subsequently used for core, everyday utility.[8]

Dollarization is here, it’s just not evenly distributed

Stablecoins are a permissionless way for retail and SMB around the world to save in dollars. Stated slightly differently, stablecoins basically expand the population that can save in a stable currency. Whatever your opinion about stables, it's uncontroversial that most humans, when they “save”, intend for their principal to retain value until they need it. As a result, “stability” is a feature of savings that stablecoins make available to consumers around the world. Many of those consumers cannot access that feature in their local currency (because their local currency loses value faster than dollars lose value). This attribute accelerates as stablecoin products become more interoperable/backward compatible with local economies (through things like stablecoin card issuing, billpay etc). This has several macroeconomic, political and policy implications that I think are pretty underdiscussed, some of which short term, and some long term:

Short Term effects of “self dollarization”

The best term I can think of for describing this effect is “self dollarization”; individuals around the world, opting first into saving in dollars, then transacting in dollars, then living in dollars, all onchain. [9]

Reducing local savings and draining local credit

Saving in dollars will first negatively impact saving in local currencies. This is already happening. A core feature of savings accounts that Americans have taken for granted for a very long time is that your principal is protected. If you live in a country that experiences bouts of inflation or crises, no amount of yield or interest on savings can make up for your hard earned income losing half its value. Stablecoins provide retail and SMB accounts a feature that their local banks can’t: effective principal protection. If your currency is losing 10% of value per year vs the dollar and you can save in dollars, it literally makes you richer over time. [10]

The secondary impact of this; self dollarization will probably also drain credit extension locally because that savings capital that’s now in stablecoins is, would otherwise be loaned out by the bank locally. This impacts lots of things; it reduces net interest margin for banks in these geos as they both have less capital to lend, and have to pay more to attract deposits. It also cycles that capital to basically fund US & European debt. As it does this, it also accelerates relative treasury demand to short term instruments[11]. As this source of demand grows, it likely makes the US/EU more susceptible to rate shocks as a larger proportion of borrowing needs to be refinanced in under a quarter than otherwise would be necessary.[12] Increasing borrowing in short duration Treasurys is already happening over the last few years; I don’t think this is purely about stablecoin demand being mostly short duration, but as stablecoins scale, they will contribute to this effect.

Transnational financial systems

We’re going to start seeing distributed financial systems that are made up of individuals around the world opting into the same unit of account. In the old world, there were several million people in a country, they shared the same border, and the unit of account, medium of exchange and store of value were all locally denominated. 

In the new world, there will be millions around the world who share the same unit of account and store of value in dollars (or whatever reserve currency exists in their time), but their medium of exchange is locally denominated. This is because for years to come, most people in a geo will earn their income in local currency and will expect to be paid in local currency for goods and services.

This new financial system doesn’t yet have a functioning fractional reserve framework (where “deposits” can be used to extend credit. This means more stablecoin adoption in a country reduces available leverage in that country (there’s just less capital to lend). In addition, most onchain lending products today require you to pledge an asset like your BTC holdings and use smart contracts to manage margin. This means more credit is (relatively) available to those with more wealth, and general credit available worldwide will either shrink, or we’ll need to adapt with new systems for underwriting, servicing, collection, remediation etc to maintain the same proportion of unsecured credit. It’s tempting to think these activities will all move onchain, but fundamentally the deepest & most liquid credit markets in the world all have a long history of high functioning property rights and nonviolent dispute resolution, and many of those systems live offline (how are you going to repossess someone's car onchain?), and blockchains/stablecoins don’t materially change the trust/property rights framework in a country. My instinct is that the answer is a hybrid (onchain where you can, but local systems where necessary). But not yet sure.

Self Dollarization in the Medium to Long Run

One way to think about stablecoin adoption is as a real time feedback loop for inflationary pressures in a country. In this way people can avoid implicit wealth seizure via inflation, because they can respond directly, in real time, to inflationary government behavior, by rotating their savings into stablecoins.

Historically, rich people every in every country have saved in reserve currencies; there’s a reason the most affluent neighborhoods in cities like New York and London have a lot of homes owned by wealthy foreigners. Stablecoins change 2 things; first, they make this behavior permissionless; it’s very difficult for your bank to block you. Second, they make it fractional; you don’t have to be rich to save in dollars - you can start with $1. 

This is a recent development that has really taken hold in the last 5 years, and will be exacerbated/accelerated by currency crises/bouts of inflation in various countries, and as a result the adoption will not be even/uniform (see my point above about Nigeria and Ukraine). 

A different way to look at this is; permissionless adoption of stablecoins enables citizens to more quickly hold governments accountable for profligate monetary and fiscal policy. Governments who inflate away their ability/trust from citizenry to print money will experience the consequences more quickly. As more and more consumers realize they can opt into this new financial system, governments will more quickly experience capital flight in times of monetary stress. Governments will react to this differently. On the extreme end are countries like Zimbabwe that jail people for utilizing digital assets. On the other end will be countries like Argentina who have permissive dollar policies from a monetary perspective and embrace stablecoins and crypto. [13]

But I do think this will be a theme in the coming decade (highly polar government responses as stablecoin adoption accelerates).

The most disruptive long term impact is that a generation from now, there might be fewer currencies in circulation. This will at least be true from the perspective of volume in circulation, and may also be true of count. This isn’t all that crazy - 150 years ago the world had fewer currencies in circulation. The transition will likely not be smooth[14], but there’s no reason it can’t happen again. A less extreme variant is we’ll have a few “superscale” currencies and lots of subscale ones, as everyone who can, saves in dollars and everyone who must, saves locally. I think we dramatically underestimate the volatility that will come with these changes (politically, from a policy perspective, from a human perspective etc).

Monetary policy dilution

In 2019 while Mark Carney was the Governor of the Bank of England, he gave a speech at Jackson Hole where (among many other things) he said:

“ financial linkages have increased leading to a faster and more powerful transmission of shocks across countries”

If 350m Americans primarily earn save and transact in dollars, and an additional 350m people (just hypothetically) distributed around the world also save and transact in dollars, then a) US monetary policy directly affects all 700m, and b) monetary policy tools utilized by the local governments in those regions are by definition (At least proportionally) less effective. If your deposit base is shallower, you likely have to increase or decrease rates more than usual to have the same impact. In addition, your economy is now even more impacted by US monetary policy than before[15]. 

Dollars vs Tethers & the power of defaults

An underexplored topic is where belief/perception is embedded in the long run. If “all money is a matter of belief”, and you’ve grown up in a world where you saved in USDT, do you believe that the stability is brought to you by dollars or tethers? This might seem ridiculous to ask today, but humans often assume the things they grow up with are defaults they cannot change, and struggle to challenge or question the default thing unless under extreme duress. 

Tether’s branding means that the default visual cue that holders see everyday is Tethers, not dollars. In the short term Tether is developing a reputation for being stable by maintaining its dollar peg and holding sufficient reserves in dollars to meet its redemption needs. In the long term it's not crazy that users/holders who grow up using USDT, might just assume Tether is a “currency” that is distinct from dollars.

An awkward financial crisis

No one can predict when, but the next financial crisis that we experience, whatever its cause, will have different mechanics than what most humans have experienced over the last 50 years, for several reasons:

• Institutional trust is at or near all time lows, everywhere in the world. In the US, this has extended all the way to repeated challenges to the independence of the Federal Reserve

• As the US government dismantles policy infrastructure and state capacity, its not super clear crisis response will have the same shape/force as in the last few crises. 

• Coordination between governments is probably also at an all time low

• More and more of the world's payments and money movement is on some kind of instant rail, which means the mechanisms for bank runs (and currency runs to a lesser extent) to happen are now much faster than they used to be. It took 19 days for Wachovia to lose $18b of deposits. It took 2 days for SVB to lose $42b.

• The growing adoption of stablecoins around the world means monetary policy from the US and Europe will have larger transmission effects into other countries than either the US or those countries expect, meaning, depending on your position as a policy maker, you are either overestimating or underestimating the impact of your monetary policy choices, and they will likely have second order effects neither country is prepared for

• Stablecoins are in an intermediate position of regulatory clarity; socially they are more accepted and everyone knows regulatory clarity is coming, and it is partially here with the GENIUS Act passing. In parallel both banks and nonbanks are forging ahead and exploring stablecoin products and infrastructure. But the regulatory regime will take a few months to stand up. The next crisis is when all the risk management around these new products will be tested, and we’ll only know how good they are on the other side of the crisis.

• Stablecoin issuers are a large and growing holder of treasuries; while the person at Treasury knows who to call at the Bank of England to have a discussion about reserves, is it clear who that person is at Tether/Circle/Paxos/First Digital? How do they look at the world? How do they react when liquidity evaporates for some period of time while redemptions accelerate? What do they do when spreads widen? What tools are available to them? This is a new “client” of the US treasury, whose needs are not exactly the same as another country’s central bank, or treasury, or an overseas pension.

• At some point, a fiat-backed stablecoin issuer will collapse. Imagine it’s holders are spread around the world. Who is responsible for ensuring each holder gets their “deposits” back? Who makes sure the dissolution is orderly?

• Most major governments around the world are fiscally quite stretched; the US/Japan/UK officially via government debt, China unofficially via bank debt. This already shows up in debt ratings, and will constrain the ability of policymakers to respond fiscally, as well as the effectiveness of their responses. 

All of this is to say, it’s going to be weird. 

The great weirding

There’s this Bruce Kovner line stuck in my head from a long time ago: 

“I have the ability to imagine configurations of the world different from today and really believe it can happen.”

I think the way the world works today (and the way it’s evolving) is already quite different from how “we” think it works. We’ll only find out just how different the next time the system experiences shock. If you’re thinking about these problems or building solutions to them, or you just think I’m wrong about something, would love to chat!

Thanks to Dimitri Dadiomov, Justin Overdorff, Ben Milne, Zac Townsend, Nico Chinot, Temi Omojola, Meg Nakamura, Henri Stern, Zach Abrams, Aaron Frank, Amias Gerety, Peter Johnson & Ryan Lea for reviewing this in drafts.

[1] I use “Americans” and “Westerners” colloquially to mean people who live in countries with stable currencies relative to USD, who thus experience stable prices of everyday goods. One caveat: there are probably some countries with relatively volatile currencies that have relatively stable prices just because of their import/export mix (Australia comes to mind). For these countries the utility of stablecoins is limited even though the currency is volatile, because price volatility doesn’t bleed into their day to day. 

Also I’ve only really excepted Japan here because i have a pretty limited understanding of it’s banking & payments system & infrastructure. These observations might also apply - I just don’t know enough to know. 

[2] Just using speed as an example - I wrote in Time to Money about protocol changes (eg ACH to RTP) and would consider stablecoins a new protocol in the broad sense (narrowly there are lots of chains with lots of different features, but broadly I think of stablecoins as a new rail with a different set of attributes that are possible, even though the implementation might differ from case to case). In the US, I don’t believe the vast majority of consumers consider speed a problem, for the vast majority of use cases that they experience frequently. There’s lots of reasons for this: domestic transfers have lots of competition for instant “posting” (instantly making the funds available for the recipient to use), including both standalone applications like Paypal, Zelle, Cash App, and pretty much every challenger payment network/digital wallet option, options like Zelle that exist in their bank account.

Of course there are lots of edges where the banking/wallet/payment provider is using an old rail or slow rail (eg bank to bank transfers like doing a transfer from Chase to Wells over the ACH rail is one notable example) but this is not a function of the technology being unavailable or worse. It’s a problem of the provider choosing not to adopt the latest available technology, which is a hurdle the stablecoin use case has to cross anyway (driving adoption of installed base with existing distribution, or creating a new installed base). Your money has to be stored in an instrument which is using an instant rail in order for you to access that rail to begin with. 

Crossborder cases are a little different for a couple of reasons. First, time to money in the consumer use case tends to matter far more to the recipient than the sender, because the recipient’s the one waiting to use the funds. It can matter to the sender as well if a late payment results in some real world/offline consequence (and I don’t want to downplay this) but in true consumer peer to peer cases, a lot of the traffic is social (between friends and family) or at best commercial adjacent. Second, the US is generally a net sender of remittances rather than recipient (both true in overall volume and transaction count). Practically, this means that a consumer in the US experiencing slow transaction speed is much less frequent than both a) as a sender or b) from a domestic transaction. 

Bringing all this together; its just going to be a challenge for stablecoins to displace domestic payments on the basis of speed alone. There might be some other use case where the advantage is clear/obvious, but speed isn’t it.

[3] You might point to foreign exchange as something that’s been around for a long time, but next time you’re overseas try changing from local currency to dollars. It will be super expensive, have high minimums and the experience will be far worse than just using something like Sling Money or Dolar.

[4] Currency volatility by itself is a huge factor but not the only factor. The important thing is how the average person experiences that volatility in their life, and how it affects prices of goods people purchase daily. For instance something like Australian dollars are pretty volatile on the spectrum, but local prices are reasonably stable.

[5] My only caveat to the concept of permissionless is that, in times of crisis, governments (or the local powers that be, that are physically near you) are more likely to use violence to collect property, and fundamentally how much permissionless wealth you retain after than encounter is a function of how much violence you can resist or avoid. For all the adoption of digital & onchain products, property rights are still secured by violence and I don’t see that going away for a long time.

[6] I remember an anecdote from a stablecoin infra company mentioning that it took them several days to transact through a $3m Peso > USDT > USD position. In fiat markets this is a drop in the bucket. 

[7] What I mean by this is, over the last decade we’ve shifted more and more away from the trade primitives/principles of the second half of the 20th century. If that period was underpinned by most of the world conducting trade mostly in dollars mediated by multilateral institutions, this more recent period is already seeing real competition from the RMB, and the Liberation Day announcement and the subsequent tariff deals mean more trade going forward will occur via bilateral country to country agreements. This shift was happening prior to 2025, but has accelerated post Liberation Day. 

[8] A lot of the infrastructure that underpins stablecoins (and eventual institutional adoption) was essentially funded by gambling. The core use case for defi for a long time (through today) has been pure speculation; it's the casino in your pajamas, allowing you to play games of luck that you pretend are skill. The fees generated from consumers repeatedly trying to get rich quickly onchain funded lots of ecosystem players like CEX’s, DEXs and others. The businesses built around this speculative activity are now often very large financial institutions in their regions, and are core nodes in the stablecoin ecosystem being built around the world.

The other impact of defi was teaching consumers around the world crypto primitives; how to use a wallet, how to interact onchain, to avoid getting rugged, etc. Those same consumers are obvious early adopters of stablecoins and onchain financial products, and can do so using the same wallet infrastructure they used to speculate. 

Gambling is profitable. This isn’t a commentary on defi/crypto. The fundamental human hormonal drives here are no different from slots or betting on horse races for most people - those just preceded crypto in terms of social acceptance. That being said, the infrastructure it has funded has the potential to stitch together a global financial system. Instead of being stitched together by large institutions in a consortium, or consumers within a single regulatory boundary, it’s consumers and SMBs around the world opting into utilizing the same unit of account.

[9] Dollarization typically refers to the adoption of the U.S. dollar as a country's official currency, either in place of or alongside its own currency. Historically a country’s political or policy leaders make the decision about adopting dollars (or not). Stablecoins make this process distributed and permissionless - a country’s president doesn’t have to make a decree, the citizens can just opt in directly. 

[10] This is more true the longer your time horizon. In a country with even medium inflation, if you’ve been saving in a locally denominated pension/retirement over the last 20 - 40 years, the compounding inflation means your purchasing power in retirement has been gutted.

[11] The GENIUS Act codified that stablecoin reserves have to be held in Treasury notes/bills/bonds that are either issued with less than 93 days maturity or have a remaining maturity of less than 93 days: https://www.congress.gov/bill/119th-congress/senate-bill/394/text

[12] 65% of Tether’s overall assets as of their Q1 2025 attestation was in US Treasury Bills with a residual maturity of less than 90 days. This number is 75% if you include repo. For Circle (as of May 2025) 45% of overall assets were in Treasury Bills with a maturity shorter than 8 weeks. 

[13] My only caveat to the concept of permissionless is that, in times of crisis, governments (or the local powers that be, that are physically near you) are more likely to use violence to collect property, and fundamentally how much permissionless wealth you retain after than encounter is a function of how much violence you can resist or avoid. For all the adoption of digital & onchain products, property rights are still secured by violence and I don’t see that going away for a long time.

[14] Carney’s comment that the “transition to a new global reserve currency may not proceed smoothly” is an understatement and I think very applicable to currency transitions of all types. Inflation is a continuous currency transition that degrades purchasing power, but shifts in the currency that’s being used are discontinuous, and degrade other types of power; if most of your savings are in a stable currency while your local currency goes into hyperinflation or is abandoned, you can find yourself suddenly becoming wealthy in your geo (more as a consequence of lots of your neighbors suddenly becoming relatively impoverished). 

[15] The world is already quite dollarized. The current regime of floating exchange rates is less than 100 years old (as we slowly moved off gold) and even the prior regime of gold had more float in it than policy makers wanted. Even without stables much of the world’s central banks operate with soft pegs to the dollar (basically everyone that can, which is why currency regimes that fail to maintain that peg are so drastic — eg Nigeria and Turkey or even the pound in the early 90s) these pegs are stable until they’re not.

• the claim status transaction type (colloquially called the “277”)[3]  available by via EDI, 

• the claim acknowledgement sent by the payer, 

• the Explanation of Benefits (EOB) or Electronic Remittance Advice (ERA or 835)

• documents available in the lockbox, and more. 

Often, a biller only needs one source to tell exactly what is wrong and what to do next, but the exact source might differ from claim to claim or queue to queue, and they don’t know which one they need for a specific claim until they see it. For some encounters the claim status is sufficient, for others you might need an EOB or the correspondence document that was sent. Less often, the biller needs to triangulate across multiple sources to get to ground truth.

With this in mind, we began by building browser agents to navigate payer portals for practices. The first thing a biller does is look up the claim in the portal; this will often have either everything the biller needs or a pointer to where they should look (which would again be just another browser tab). Next, depending on what they learned, they’d potentially look in other places; checking the patient’s eligibility to figure out if there was another payer that the claim should have been sent to, checking the EOB for the claim to get the payment information, and more. Ultimately this information drives a decision about what to do next. This process is incredibly tedious; it’s a lot of copy-pasting data between tabs, waiting for payer websites to load, cross referencing information, and then reasoning about why the claim is in its current state. No one enjoys it, and it’s a massive time suck for billing & RCM operations teams. Some organizations have whole teams who only do this. In others, every team is responsible for logging into the portal and looking up the claim themselves.

In theory, an RCM team should be able to achieve all this by utilizing the available EDI transaction for claim status (the 277). In practice, this only gets you part of the way there. 83% of insurance companies (2,900 out of 3,500) don't support automated claim status checks, forcing manual portal lookups anytime something goes wrong. 

For the ones that do, you encounter myriad fidelity issues; everything from finding the exact payer to report on the claim, all the way to extracting sufficient signal about what to do next. The quality of data you get varies widely between payers and between different claims from the exact payer, and the richness available from a specific payer varies widely between 277/EDI transactions and what’s available to a human in the portal. I’ve long believed that payers often degrade the communication channels available to machines because they can get away with it, and providers are just as likely to blame their clearinghouse for any issues. It’s harder to degrade portals though (or other human interfaces) because then the humans can really complain and know who to blame. As a result, you see this disparity where human interfaces are incredibly privileged and have really rich data and functionality, while machine interfaces consistently lag behind. For example in comparing the 277 response and the portal data for the exact same encounter from United Healthcare (the largest and arguably the most technologically sophisticated healthcare company on Earth), you can on average extract 2x as many fields from the portal as you can from the 277 transaction (37 in the portal vs. 15 in the 277). Basically the machine interface only has half the depth as the human interface:

The worst part is this isn’t consistent; while the portal is always richer, the 277 might actually be sufficient for the problem you’re solving. You just don’t know until you see the results. And there are a handful of large payers (Medicare and Tricare in particular) that don’t support the 277 transaction type.

What this means in practice for a billing team is you spend lots of time hunting and sniffing around various places to piece together all the data about a claim. To understand what’s going on with a claim, you might spelunk through 5 separate tabs or applications; your EMR, PM, Payer Portal, Lockbox Portal, and payment posting system. Each unique interaction requires 2 - 4 minutes of clicking, copying, pasting, and waiting for a page to load (often only to find out the payer is down or something else you couldn't know in advance).

We built a vertical deep research agent that automatically checks all these sources simultaneously and synthesizes the results—like having a superhuman biller working 24/7.

Introducing the deep research agent for healthcare claims

To solve this, we developed the most comprehensive claim status product in the world. We did this by giving our agent all the tools that a human would have, and all the tools a machine would have. As a result we can access:

• EDI transactions (mostly 277 real-time claim status and the 271 eligibility transaction, but can integrate others as needed) 

• Direct API connections to large payer interfaces like Availity and United

• Browser agents for

  • Payer portals - this allows the agent to see exactly what a human would see when they log in. We utilize infra providers like Cloudcruise for this

  • Banks

  • Lockboxes 

  • EMRs: this enables us to consolidate clinical data about the encounter (we utilize a combination of RPA, browser agents and computer use infra providers like Nen for this case)

  • Pretty much any system a human biller can log into

In addition, we’ve begun pulling in payer policies and contract data (including rates, cpt codes, requirements, and more) in certain cases, as well as extracting financial data directly from EOBs. These are extremely tedious tasks that (in many cases) would take a biller several minutes per claim to pull all together. We find all the data knowable about a claim, decide what to do with it, based on your rules/configuration, take actions on it in your system, and of course allow you to chat with it:

How it works

While traditional deep research agents often start with a freeform prompt and synthesize a ton of breadth, we start with your encounters and synthesize a ton of depth. You can get started with a thin demographic extract of the relevant encounters you want to investigate. The “thin” -ness of this is important. Many technology providers in the revenue cycle/claims space require practices to pull large amounts of extremely detailed claims data, and then spend time and effort normalizing the data into a format that allows them to run analytics. Our approach is the opposite - we request ~10 fields per encounter, retrieve the claims data from every source outside and inside the practice, and normalize it ourselves.

The beauty of this is that healthcare practices can start to see results within minutes. Almost any PM or EMR can generate this list of demographics quickly (we already interact with thousands of physicians and have yet to encounter a single EMR that can’t generate this).

To do the job, we need a few types of tools that are difficult to give a more generalized agent:

Open access tools

Open access tools are accessible on the open web, and definitionally accessible to a traditional deep research agent. These include data like payer policies, companion guides for EDI connections, NPI data, Medicare rates, and more.

Privileged access tools

These are tools where you’ll need API or EDI/Clearinghouse access to payer information about a specific encounter. This might be a claim status, patient eligibility or a claim acknowledgement. We currently use Stedi for EDI access, and have direct integrations into a handful of payers for privileged access. You can get access to these tools without specific credentials from the healthcare practice.

Credentialed access tools

These are tools where the agent needs the practice to grant access. The way to think about this as a healthcare practice is; “what’s the set of logins you’d give to a new hire on your billing team?” Access might be login credentials to payer portals or a practice management system or bank account, or might be internal documents like SOPs or payer contracts. These are effectively the same tools a human would use to investigate claims. 

Our system then reconstructs your accounts receivable by seeing it the way insurance companies do—giving you the financial data that the insurance company has on file, about your claims. This involves giving the agent a deep suite of healthcare-specific tools that optimize first for getting any information on as many claims as possible, as much depth as possible on problem claims, and leveraging reasoning to interpret, and analyze the information available, and decide what tools to use next.

How we use this today

Today, we use this to enable clients to quickly understand which claims in their backlog need attention, and what to do about those claims. Using our deep research agent, they can answer questions like:

• How many claims have been paid vs. not. 

• How much was paid on each claim, and when? 

• What’s the outstanding patient responsibility for this particular claim, or group of claims?

• How many are outstanding or denied, and why?

• Why was a particular claim denied? 

• Did the medical record support the coding available on the claim?

• Which claims should I focus on?

Who could use this

We started out by building for the AR follow up use case (just tracking insurance claims that are somewhere between “submitted” and “paid”. Along the way, the ROI is clear: For each claim, every source they have to check is 3 - 4 minutes of human interaction time (not including reasoning about what decision to make). For every thousand claims you’d basically save a full time employee a week of detective work. We’ve already encountered several use cases for this approach:

Enabling practices & outsourced billers to monitor claims

Practices use us to monitor claims in their backlog; these include no-response claims (where you haven’t heard from a payer in a number of days) or denied or appealed claims. In this use case, we give you more data and cover more payers than available via EDI, and save your team the time they’d spend looking up these claims by hand.

Enabling practices to monitor their BPO

We’ve helped a number of practices that don’t have great visibility into how their BPO is doing measure how much is outstanding, by payer, and why. For these folks we provide out of the box denial trending to help measure their AR and quickly figure out where to focus and what questions to ask.

Payment Posting & Reconciliation

This one was surprising. In certain cases, it's become easier for practices to use us to extract payment information, patient responsibility and EOBs directly from the payer portal. This is due to a combination of things; some payers still send these details via paper, or a new provider coming into a practice might require a change in EFT enrollment, or something else. In these cases, we make it easy to go from “what’s going on with this claim” to “here’s an EOB you can use to post a payment” in just a few clicks.

Aged AR

If you are a healthcare practice or an outsourced biller or a large BPO, or you otherwise have a large backlog of claims that need investigation, our deep research agent can help you understand your AR in just a few days, with minimal people overhead. 

Acquisitions & Transitions

More recently we’ve begun helping some practices get a crisp understanding of their AR as they transition between BPOs or from a BPO to bringing their RCM in house. For this problem set, it’s often far easier to rebuild the AR from the payer perspective than to make sense of your old system’s claims export and trying to smush it into your new system. For these folks, we make it easy to keep track of your AR as it changes hands. If you’re acquiring a practice and transitioning their claims, or you’re an outsourced biller and you’ve won a large client and you want to quickly get to the heart of what's happening with their AR, this is perfect for you. Think of it like claim status on steroids.

What comes next

To date, most of what we’ve given the agent access to are “read” actions. It performs lookups from several trusted sources and consolidates all the information to present and synthesize it for you.

Next, we’re going to do two things: 

First, we’ll continue to expand the specific external tools it has access to. This will include pulling in items such as payer policies, payer contracts, contract rates, lockbox documents, and more. Our objective is to enable the agent to gather all the necessary information to draw a conclusion. More broadly, enriching the available toolset expands who can use it, and for what.

Second, we’re giving the agent “write” access. This will enable the agent to adjust & advance claims in your practice management system, including tasks such as adjustments, write-offs, actioning worklists, and adjusting queues. 

More to come on this. If you’d like to work on this or think it you could use it, please reach out.

Thanks to Chet Montefering, Marlo DeLatorre, Inderpal Singh, Murad Salahi and Trent Lowe for reading this in drafts. 

[1] Think of this as a way to group or cluster a number of claims that are in a similar state based on the information available. RCM operations leaders typically organize teams of people around a queue so they can build up context and expertise and execute the queues more quickly.

[2] Walking into your doctor’s office and use your insurance, is just the beginning of a complex and (often) long financial and operational process of the doctor getting paid. Your doctor submits a claim to your insurance company, which is essentially a detailed bill explaining what services were provided, what problems you presented with, which specific practitioner(s) saw you, where,  and how much they cost. But unlike paying for groceries where you swipe a card and get an instant authorization, your doctor might wait months to even know if the insurance company received the claim. The only way to find out is for someone at the medical practice to manually hunt for answers: logging into insurance company websites, calling insurance call centers and piecing together fragments of information from different sources. For a typical practice managing thousands of claims across dozens of different insurance companies, this detective work consumes an insane amount of their billing staff’s time. Its like trying to track packages from 50 different shipping companies, each with their own tracking system, and most of them don't send you notifications when something goes wrong.

[3] Healthcare counterparties exchange data utilizing standardized electronic messages called EDI (Electronic Data Interchange) transactions, each identified by a three-digit code. Think of these as different types of automated conversations between healthcare providers and insurance companies:

The Eligibility Check (270/271): Before treating a patient, providers send a 270 transaction asking "Is this person’s insurance valid?" The payer responds with a 271 containing benefit details, copay amounts, and deductible information—essentially a digital insurance card check. Hilariously, the amounts the patient is responsible for often change after the claim is adjudicated, so even after collecting a patient’s payment upfront, providers often have to either bill or refund the patient for the difference after the claim is fully adjudicated.

The Claim Submission (837): After providing care, providers submit an 837 transaction—the actual bill containing diagnosis codes, procedure codes, provider information, and charges. This is the healthcare equivalent of mailing an invoice.

The Claim Status Inquiry (276/277): When weeks pass without payment, providers send a 276 transaction asking "What happened to my claim?" The payer (sometimes) responds with a 277 containing the claim's current status—pending, processed, denied, or paid.

The Payment Advice (835): When a payer actually pays a claim, they send an 835 transaction (Electronic Remittance Advice) explaining what was paid, what was denied, patient responsibility amounts, and adjustment codes explaining any differences from the billed amount. This is analogous to the EOB (Explanation of Benefits) that you might receive from your insurance company after the claim is adjudicated; the main differences are that the 835 is 1) Machine readable by default and 2) meant for the doctor not the patient to consume.

Sorry for the buzzword bingo.

Deterministic vs. non-deterministic

In this context, the level of determinism is driven by how likely it is that the inputs, the steps in the execution path, or the outputs in a particular workflow will be different in substance between workflow runs. On the fully deterministic end of the spectrum is effectively an API: the payload (input), endpoint (path), and response (output) are the same every time. On the non-deterministic end of the spectrum is something like a deep research agent: the prompt + context (input), calls (path) and the output are different every single time. For the moment I’m focused on how deterministic the execution path is because LLMs already do a great job extracting structure from unstructured data, and on the input and output side responses are (relatively) instant, making them easy to verify (vs. a task execution which can take several minutes)

Language models can help make the portion of the web built for humans (most of it) very legible to machines - this drives a lot of the boom in AI agents. Initially, when we started Substrate to deploy browser based AI agents in healthcare RCM, I thought the use cases would require much more nondeterministic approaches because we were targeting tasks that semantically were the same, but occurred on different surfaces, and utilized different data and context. 

For example, a very common task that basically a high percentage of healthcare claims (>40%) that are billed to insurance go through is getting a claim status checked. Often, after a claim has been successfully submitted, the practice or biller has to do subsequent actions to get the claim paid, or it just takes a long time for the payer to respond at all (these are called “no response” claims). These actions might include changing the coding information on the claim, adding more information like authorization or licensing data to the claim, or submitting medical records to the payer. In order to understand what actions need to be done, the biller needs to check the status of the claim. There are multiple ways this is a highly variable process, including:

1. Payers have many transmission mechanisms for telling the practice that something is wrong, including mail (typically called “correspondences), fax (rarely), email, portals, ERAs, and EDI (ERAs & EDI being the most automated ways to do it). Of ~3k payers in the US, ~450 are EDI capable.

2. The specific codes and descriptions payers use differ (the substance of the message), and also different payers often use similar language and codes to mean different things

3. In order to actually respond and make the changes required, even though semantically what the biller is doing is the same (appealing a claim), the portals are different and the changes are often different.

For example, all of these denial codes mean the exact same thing (that the practice needs to submit a (combination of) medical record documents to the payer):

And this is just 4 payers. The exact combination of clinical documents that will satisfy this type of request are more a combination of tribal knowledge and trial and error, than any context you can explicitly extract from the claim status itself (or from any other source that’s consistently available)

A single human can easily manage this variety - particularly the high diversity of ways to find out a claim requires more information, or the high diversity of steps to fix a claim, or just navigating to a portal to figure out what’s going on. As a result when we started Substrate I had the impression that we’d have a single “agent” with a massive prompt that allowed it to encounter a new portal for the first time and do the right thing. In hindsight that wasn’t correct. 

For example, in the browser a VLM like Operator allows you to specify an objective and ask the model to complete it, but the path it takes isn’t typically defined by you. I consider this the non deterministic approach. The alternative is treating the browser like an API and utilizing models to handle the long tail of edge cases that exist, hence making human accessible workflows available to machines, and making them permissionless. Zi has a good write up on the technical tradeoffs here. I’m mostly focused on the commercial/experiential ones. 

This included input data about denials that came in lots of different, nonstandard formats, many different payers and plans with different policies and preferences, and a wide range of choices about how to fix a claim.

But the entire time I’ve had this deterministic/nondeterministic tension in my head - ultimately the non-deterministic approach allows you to handle many many more unexpected cases that the agent might encounter, but the amount of context required to handle them consistently and deliver a deterministic output, which is ultimately what  enterprise use cases value, is insanely high. The more I see and the more I dig in, the clearer it is that the deterministic approach utilizing models for edge cases and self healing/auto healing beats the pure nondeterministic at enterprise scale.

Enterprise context = enterprise constraints

In enterprise context (which to me means massive scale, often in “sensitive” environments - eg healthcare or financial services where I’m familiar), what users and developers really want is an API. Agents are a means to that end. In these environments, entities have lots of rules and regulations to remain compliant with, and high exception rates often lead to bad real world outcomes, and audits. Historically, enterprises haven’t needed to re-specify their objective when running millions or billions of transactions per day. Why opt into that now?

Nondeterministic approaches can help when there’s a high amount of variability in outcomes. At any real scale, you can’t really tolerate this - even a .0001% exception rate is 100 exceptions on 1m transactions. A staggering number of enterprises execute many millions of “transactions” a day. For read only transactions you have some tolerance bc you can check the output is formatted correctly and re-try the read, and the only system harm is load risk. But if there’s a model free alternative that is completely deterministic and the customer/end user expects a deterministic result, enterprise customers would choose that 10 times out of 10. In that scenario it’s not clear why an agent choosing its path would be better than an API that works the same way 100% of the time with clearly defined edge cases/exception handling that are well understood in advance, and self healing/auto healing for cases where the agent encounters a surprise along the way.

For write actions, a non deterministic to probabilistic approach is literally intolerable - deploying exceptions into a system of record would create meaningful financial and operational (and clinical in the case of healthcare) repercussions. No one wants that.

As an example, Substrate’s customers include specialties like oncology, orthopedic care, urgent care, and behavioral health. Our system helps them check claim statuses, appeal denials using medical records, evaluate medical records for medical necessity, and more. These customers want a) something that works the same every time and b) is correct every time regardless of volume. While it’s possible that a nondeterministic approach can be correct every time, it’s insanely hard to evaluate it as such if its execution path differs each time. Right now to achieve this we use a hybrid approach as different contexts require different levels of sophistication; scripting/pure RPA for environments that are extremely static, the code-gen approach Adrian describes here at Cloudcruise (big fans) for browser environments that are more dynamic, and a VLM based approach in desktop environments.

Where a 100% nondeterministic approach works

There are at least two contexts where a 100% nondeterministic approach works. The first is consumer products. In these cases, you’re rarely doing that many transactions per customer and you want each transaction to be very high-quality and totally personalized to the consumer. In leisure use cases “exceptions” (or deviation from the path) can be kind of a feature because they surprise and delight the consumer, and with high quality personalization can help them discover choices that satisfy unspecified (or poorly articulated preferences).

The second context where a completely nondeterministic approach works is in the world of voice agents. In this world, even though the outcomes are also deterministic, the path can be so nondeterministic that maintaining a script that can manage all the cases becomes ruinously expensive. The person the agent is talking to might be having a super bad day, or for many other reasons the things they can say diverge wildly from the “happy path, that having a conversational agent that can reason in every interaction step  and introspect on the best next words to get back on script can actually be a huge step function improvement. 

In the voice agent context you can think of the human as the equivalent of a “website” in a browser agent. A website in a single interaction has a fixed amount of information and a fixed number of available actions. A human, on the other hand, is persuadable - the information an agent can extract is effectively bottomless, and the actions the human can take in partnership with or in response to a conversation are effectively boundless. 

Why this matters

Browser based agents extend the surface area of problems that are accessible to software because the vast majority of workflows that happen in the browser actually are deterministic and the hard work was maintaining scripts and handling cases where minute changes to the UI resulted in a broken workflow. Now models can auto heal and handle minor changes without a human in the loop. I’m still developing a framework to decide when to choose either path. If you’re building in any of these domains and you have a strong point of view, I’d love your take. 

• Patient + caregiver keeps a binder of as much medical information as possible (medical records, prescriptions, notes etc). 

• Patient + caregiver spend a lot of time researching details around the diagnosis: available therapies, known side effects, lifestyle changes, other specialists etc. 

• Patient + caregiver collaborate around care. This includes everything from logistics (who accompanies the patient to each visit) to lifestyle changes, supplements etc.

This isn’t exhaustive but it is directionally right. I think it’s now possible to combine all of these into a single tool, that the patient and caregiver will use. This would look like:

1. AI scribe on the patients phone (very similar to the Abridge patient app). Records the visit, extracts key clinical context, generates reminders and timelines.

2. Integrated Deep Research agent that 

   1. utilizes the specific visit transcript + patient demographic profile + summary + the historical visit notes as context, and makes it easy to add more context

   2. Generates a custom prompt to grab information from the outside world that the patient would want. This can vary based on the complexity of the condition, but would include everything from specialists, clinical trials, alternative therapies, research in other languages etc

   3. Enables the patient and caregivers to quickly do new research with the patients history as context.

3. Collaboration tools (this can be as simple as a WhatsApp style group chat that is integrated into the experience) to enable the patient and caregiver to just talk about the logistics and substance of care.

I suspect you could do lots more interesting things like integrate into MyChart, integrate billing etc, but ultimately these 3 pieces of functionality can be built permissionlessly and actually belong together.

I wrote a while ago about “Voice” as a new healthcare primitive, based on my experience using Abridge as a patient and on Carbon’s experience building a fast growing AI scribe. At the time the enterprise opportunity felt pretty obvious because I could directly observe the clinical and operational impact Carbon’s AI scribe had. 

The provider impact was obvious to me, but seeing the explosion in deep research agents, it’s pretty clear they can lift a ton of cognitive load for patients as well. The other nice thing is that this problem is pretty uniform for patients around the world. If you’re building this I’d love to learn more (and be an early adopter).

1. We’d ship a new payment feature

2. Immediately fraudsters would show up and “pen test” everything; stolen cards, stolen creds, stolen identities, payment limits, social engineering, software vulnerabilities etc in ever more creative ways

3. Fraudsters would quickly coalesce around any weak points or vulnerabilities and rapidly extract real dollars programmatically from the system

4. The risk and fraud data teams would go into overdrive patching up the vulnerabilities

5. Fraudsters would move on (I assume to the next weakest point)

In practice, there’s always some fraud in financial services. But payments products are weakest just after launch, particularly in more complex platforms (ie the more different instruments and types of money movement that a platform has, the more unexpected combinations are available for a fraudster to exploit.) 

Fraudsters swarm to test new holes and drain funds while the team is getting their feet under them, and I can’t say this for sure but it definitely feels like fraudsters collaborate and communicate with each other when a vulnerability is discovered, and all try to exploit it. 

As instant payments gain adoption around the world, in a time when LLMs make more types of automation, social engineering, impersonation easier, I only expect this dynamic to accelerate. There are already a trickle of examples out there of voice agents or deepfakes being used to defraud companies to dramatic effect, so I’d be surprised if this isn’t happening at scale. As browser agents and frameworks like MCP get better, you can expect more software surfaces to become vulnerable. I’m not as experienced in other financial domains (eg lending, insurance etc) but I suspect a similar dynamic is true in those as well). 

Medium term, fraud detection and prevention is an active domain that requires financial services teams to continuously engage, detect new patterns, model them, and deploy those models to protect the company/financial services provider. It’s inevitable that some money will be lost, as fraudsters are human, and humans are creative in unbounded ways, and successfully stealing money is extraordinarily lucrative.

In addition, losses are not always due to the company or product being bad or weak. For example, most stolen debit cards are breached from merchants not issuers, but issuers are ultimately on the hook due to Reg E (this is as it should be)

The opportunity

There’s an opportunity for using AI agents as adversaries in a red team/blue team model. Here’s how it could work:

• Teams of human and AI agents are let loose inside the system

• This could be in staging/post QA, prior to going to GA (this is probably best practice)

• In prod, agents should be able to exfiltrate actual dollars into an actual external /off platform bank account (controlled by the company)

• This can be continuous, on both pre launch products that are already moving money, and live products that are already live to customers

• Process would require teams to continuously monitor patterns of exfiltration and either

  • Adapt models to detect and prevent them

  • Close product gaps that make exfiltration possible

• If you do this you’re ultimately constrained by GPU, but could drive step function improvements in risk losses, which at the scales of large fintechs, this could have a meaningful impact on earnings

• As off the shelf agents (like Operator) and frameworks (and MCP) and auth get better, this should become easier and easier to implement

Open questions

1. Using stolen credentials and stolen instruments is a large vector for fraud, and is also literally illegal (a long time ago I thought it would be a good idea to actually try to buy stolen card data when it hits the dark web and preemptively add them to a block list. My compliance team was not a fan.) Given that stolen payment instruments and stolen/synthetic identity are two of the largest and most active vectors for financial fraud, it feels like a missed opportunity to exclude. 

2. I’ve written before about authentication. I think in internal enterprise context this is reasonably manageable, but having programmatic ways to handle and orchestrate credentials will help scale something like this.

3. In a world where increasingly large numbers of financial activity moves onchain, adding this kind of system to test smart contracts will be super helpful. If you believe the noise about AI agents relying heavily on stablecoins to make and receive payments, this is a natural evolution.

—

The Wall Street Reform and Consumer Protection Act, better known as Dodd-Frank, passed in 2010 in the shadow of the financial crisis. The Durbin Amendment was part of Dodd-Frank, and was passed to limit the fees merchants paid to banks for debit card processing (commonly called interchange). The regulation applied to banks with over $10 billion in assets (essentially exempting smaller banks such as community banks, who have a strong distributed lobby around the US).

Intended Consequences

When Durbin went into effect, it set a ceiling for debit interchange fees at 21 cents and 5bps of the transaction amount for regulated institutions (the implementation of certain fraud measures allowed banks to add a cent, so effectively Durbin regulated interchange is 22c and 5bps). Technically, card networks could charge any amount below the cap, but as commercially minded firms, Visa and Mastercard set interchange at the ceiling. This effectively split debit interchange into 2 tiers; Durbin regulated at 22c and 5bps, and Durbin exempt, which was effectively unregulated[1] and works out to somewhere around 120 - 160 bps depending on your transaction mix. Incumbent banks (Chase, BofA, Wells, PNC, Citi etc) made up 80% of debit cards issued, so the Durbin amendment materially cut the costs of debit card processing for merchants around the US. Early on, the mechanics worked as intended - Durbin regulated banks, which made up 80% of the debit volume in the US, saw their interchange revenue cut significantly. Practically what this means is, if you pay $5000 for an Airbnb with your Chase Debit card, Chase gets, ~$3, but if you pay for that same Airbnb with your Chime card, Chime gets ~$85. Exact amounts depend on how the transaction gets categorized and the specific agreement that issuer has with the card network, but the order of magnitude of the delta is correct.

To put this in perspective, in Q3 2011, just before Durbin went into effect, aggregate annualized debit interchange across the US banking industry was $19.9Bn. In Q4 2011, that same figure was down 7% at $18.5Bn, even when aggregate transaction count grew 11% during that same period. [2]

Unintended consequences

Banks make money off consumers by a mix of payment revenue (typically interchange, wire fees etc), net interest margin (the spread between what banks earn lending money and what they pay as interest on your checking and savings accounts) and other fees (monthly fees, dormant account fees, overdraft fees etc). Over the last 2 decades, as interest rates have hovered at all time lows, the mix of revenue from depository consumer banking has shifted heavily to payment & fee based revenue, and less on net interest margin. In addition, if you were a bank customer that lived paycheck to paycheck (or otherwise had high income and expense volatility) then your bank couldn’t rely on net interest margin to monetize you anyway, and relied much more heavily on fees.

The cost of legacy infrastructure

Coming into the last decade, most US banks had fairly high costs to service deposits, driven by legacy (often on-premise) infrastructure. For example (circa 2014), a bank that held balances on infrastructure provided by services like Fiserv, FIS or Jack Henry (treat these costs as directionally correct, rather than precise), would pay on average $3 per month for each account. So, regardless of whether an account was active, the bank paid $36 per year for that account. This didn’t include any other costs: shipping and processing physical checks, card manufacturing and fulfillment, fraud losses, and customer support costs, to name a few. This amount scaled linearly with each additional cardholder account (Eg if a cardholder had both checking and savings accounts, they’d cost that institution $72 instead of $36) at the same institution. Theoretically, banks could afford to play a cross-subsidy game, enabling high deposit customers to subsidize paycheck to paycheck customers. [3]

The true irony here is that incumbent banks were paying $36/year for something with a $0 marginal cost (a database table + eventstream).

Incumbent banks still have high infrastructure costs, because even though low cost infrastructure options exist, the transition is slow and tentative. This is driven by organizational drag and byzantine tech stacks. Imagine you manage the deposit programs at Wells and in 2022 you could either choose to migrate from FIS to Marqeta and cut your costs by 50% (just making these numbers up) or you could instead launch a voice assistant? If you get the Marqeta switch wrong, a bunch of customers’ cards won’t work and you lose a bunch of spend, and you’re losing your job. If you get it right, margins improve in a few years. You took a ton of operational risk to get there, and might not be around to reap the rewards when the full savings and flexibility are realized. If you launch the voice assistant someone will invite you to speak at Money2020. For personal career incentives, there’s not enough upside. Compounding this is that traditional card economics are complex to model and understand - as you’ll see in the Visa interchange fee schedules, you have to make a ton of assumptions about your transaction mix to understand the revenue impact, and even then, the cost side of the ledger is quite opaque.

A sea change in distribution

Lastly, this might sound obvious but, in consumer finance, distribution is king (this is still true today). Over the last hundred years, winning at distribution meant having more branches accessible to more consumers. By doing so, you’d capitalize on both increased foot traffic and more impressions (as each location serves as both an endpoint to sign up new customers, and a billboard to advertise your services). In the years since the iPhone launch in 2007, the growing ubiquity of smartphones, combined with the increasing depth & richness of mobile apps has turned branch based banking from a distribution advantage over the previous 100 years, to an operating expense liability[4] over the last ~10, which has dealt (and is still dealing) a triple blow to incumbent banks;

1. app stores are a lower cost, underexploited mechanism for consumer finance distribution, than branches

2. incumbent banks continue to pay for rent and headcount to maintain branches (and to a lesser extent, ATMs) and face headwinds when trying to close them

3. mobile applications have gotten sufficiently rich & deep that the share of banking functionality that requires in person interactions gets lower everyday.

I can’t overstate the impact of #3; there just are simply not that many banking interactions for which a customer needs to be in person. The two I can think of that remain are 1) certified checks, when you need them and 2) mortgages which require wet signatures (fewer and fewer mortgages require these as time goes by). One early insight we had at Cash App was that if we could just be the number 1 finance app in the appstores, we’d get the digital equivalent of foot traffic; everytime someone navigates to the finance section, they’d see your app first. We also recognized (this came later) that if we could be a top ranked app (not just in finance), we’d get the digital equivalent of impressions; all the algorithms would pick us up as a top app, all the editors would include us in their lists, and everytime someone got a new phone for the holidays, as they browsed top apps to download, we’d show up.

This focus (on mobile as a distribution mechanism) was not exclusive to Cash App, but incumbents weren’t thinking about it (or at least weren’t behaving like it was existential). If you’re Jamie Dimon, making sure Chase is the #1 consumer finance app probably has never crossed your mind, even though Chase as an institution can basically serve every single consumer finance need to date (maybe except crypto, to the extent you consider that a “need”). At Cash App, we valued mobile so much that we sacrificed our web app; choosing to have insanely rich and deep mobile experiences, while our web/desktop presence was useful but minimal. After 2015, we basically never prioritized feature parity between web and mobile. This remains true today. There’s lots of operational consequences for this that aren’t worth getting into here, but this focus on mobile has contributed to Cash App being the #4 most downloaded app of 2021 in the US.[5]

Second Order Effects: Rise of the underbanked

Historically, banks could afford high legacy costs through a gigantic fee pool comprising all the sources above (payments, net interest margin and other fees). A sustained ZIRP [6] environment compressed net interest margin by making deposits less profitable, and the Durbin amendment caused paycheck to paycheck consumers to be unprofitable overnight. On net $14 billion in annual (mostly interchange) revenue evaporated for Durbin regulated banks[7] in the years after it went into effect. For Durbin regulated banks, acquisition, retention and reward spend on paycheck to paycheck consumers had to collapse.

Passing costs on to consumers via fees

One obvious way to offset the reduction in interchange revenue was to increasingly rely on overdraft fees. Overdraft fees existed prior to the Durbin amendment, but after 2011, banks increasingly relied on the practice of charging customers a large fixed fee whenever their balances dropped below $0, stacking those fees by enabling a customer’s transactions to continue to be approved even when their balance was below zero, and eventually (prior to the crackdown) re-ordering transactions that happened on the same day, so that the customer’s balance would drop below $0 earlier in the day, so the customer would incur multiple overdraft fees in that day. For example imagine you had $100 in your balance, and 4 transactions in that day, for $20, $15, $37, and $90, in that order. Banks using re-ordering, would process the largest transaction first ($90) so your balance would be at $10, and each subsequent transaction would drop your balance below $0, and thus incur an overdraft fee (on average about $35). So in the sequence they occurred, you’d pay $35 in overdraft fees and have a overdrawn balance of -$97.00. In re-ordered sequence, you’d pay $105 in overdraft fees, and have an overdrawn balance of -$167. To cap this off, between 2009 and 2013, overdraft fees increased 15% from an average of $25, to $30, with the largest banks pricing overdrafts at $35 per overdraft. [8]. Fortunately, overdraft re-ordering is basically extinct as it was one of the first practices the CFPB cracked down on after the agency was formed.

The acceleration of overdrafts (and other deposit fees) had a few consequences. First, they helped replace lost interchange revenue. Second, they removed the subsidy; customers with sufficient balances would be monetized directly via net interest margin, and wouldn’t incur overdraft fees. Customers with repeat overdrafts would have their accounts closed and (often) be sent into collections, and have their overdraft status reported to consumer reporting agencies like ChexSystems[9]. This would enable other banks to identify and decline affected customers when they attempted to open a checking account. Finally, customers who incurred overdrafts and actually paid them were sufficiently profitable to keep.

The other mechanism for recouping lost interchange fees was to introduce and enforce minimum balances and monthly deposit fees.

Chase Fees

Wells Fargo Fees Again, deposit fees existed prior to Durbin, but the Durbin rollout increased bank’s reliance on non interchange fee structures. Overdrafts, account service fees, and minimum balances were often deployed together. You could maintain a minimum balance and point your direct deposits at the account, and you’d incur no deposit fees (by policy) and be really unlikely to incur overdraft fees. Or you could pay monthly service fees, keep a low balance, and run the risks of overdrafts. According to the Federal Reserve [7] changes in deposit fees were sufficient to only offset roughly 30% of the lost interchange income.

Macro Background

Durbin was passed in the shadow of the Great Recession and a multi decade long run trend of greater income and expense volatility for consumers. Regardless of whether Durbin had gone into effect or not, the reality is that for the last several decades, more and more American consumers live paycheck to paycheck every day and have less of a financial cushion. This structural long run trend makes them less likely to be bankable by Durbin regulated banks (or more likely to be monetizable via overdraft fees, depending how you want to look at it). There’s some evidence that this migration away from incumbent banks was already happening prior to 2011 - one study published in 2010 cites over 4 million consumers moving their bank relationships from “too big to fail” banks.[10]

Focus on a richer consumer

In addition to no longer being able to profitably bank this segment of customers, Durbin regulated banks stopped paying to acquire and retain them, and shifted acquisition and retention dollars to customers who would be surer bets. Tactically this meant - ad dollars, sponsorships and channels used to acquire paycheck to paycheck customers were drained of funding. Those dollars went instead to reducing the interchange hole, and to fund incentives of wealthier customers - those incentives would be designed to promote behavior that increased the odds a wealthier customer would stick around - such as Chase’s current $500 bonus to customers who stick around for 90 days and maintain a minimum balance of $5000. You’ll notice basically zero mass market neobanks use this as a tactic - they simply don’t have to.

Seeds of their demise

The combined withdrawal from marketing and retention channels and passing on fees to this segment dramatically expanded the underbanked/unbanked population that most consumer neobanks have been going after for years. Obviously there are other reasons for consumers to be unbanked, such as being newly immigrated or undocumented, but as wages have stagnated, fewer and fewer people meet the criteria to avoid $35 overdraft fees a few times a year. In many cases, they’re explicitly locked out by the consumer reporting agencies such as ChexSystems. This effect strengthened competition in unexpected ways.

Payment acquiring

Square and Stripe were both started in 2009. Square focused on using mobile as an access point to expand card payments, and Stripe focused on internet payments. Square, Stripe and PayPal were early, large beneficiaries of the Durbin Amendment, for two reasons. First, they charged merchants stable take rates that abstracted away the complexity of interchange (as opposed to industry standard cost-plus). Second, they (naturally) processed a mix of debit and credit card payments, and 80% of debit card payments are on cards issued by Durbin regulated banks, and debit is a meaningful portion of the mix of card payments (for offline payments, debit is close to 60% of the mix both by volume and count.). Overall, debit is the single largest consumer payment method in the us.

These companies all charge merchants variable fees (2.75% in Square’s case, 2.9% in Stripe and PayPal’s case) as well as fixed, so when Durbin went into effect the proportion of their volume that was on debit expanded meaningfully in margin. Early in Square and Stripe’s history there was a perception that interchange was a bad business, margins would trend to zero, and these companies would need a second act in order to sustain themselves. While they’ve all had multiple acts at this point, that perception missed the fact that a regulatory change made interchange far more profitable for acquirers, and by focusing on onboarding new merchants into the ecosystem, they’d be much more able to sustain margins (vs trying to process for large merchants like Target and Walmart who already have large operations optimizing down their interchange costs with their payment acquirers).

Competition in consumer finance

Three types of consumer finance opportunities emerged post Durbin.

Overdraft Protection

First, companies like Dave, Earnin, and Brigit emerged to provide programmatic overdraft protection, extending working capital to affected consumers in exchange for predictable, lower fees. At launch, Dave charged $1/month and would extend $100 if your balance dropped close to zero, directly deposited into your account. As a consumer, you could choose to subject yourself to unpredictable overdraft fees, each averaging $35, or you could pay $12/yr and never pay an overdraft fee again. These companies used overdraft protection as a wedge, gained a meaningful amount of customer adoption, and have now expanded to a full suite of no fee banking solutions, built on top of Durbin exempt banks and funded by Durbin exempt interchange, thus arbitraging the regulation yet again.

Debit Card based P2P

Second, companies like Cash App, Venmo and PayPal relied on low Durbin regulated rates to fund card loads in the early days, prior to the Visa AFT (Account Funding Transaction) and the MasterCard MoneySend transaction becoming widely available. Durbin regulated rates provided a way for customers of P2P platforms to fund their digital wallets at much lower cost per transaction (to the platform) than Durbin exempt interchange, by linking a debit card. Debit still cost more than ACH, but debit pulls are simultaneously faster and more reliable. These products enabled customers to add funds to their digital wallets by linking a debit card. The platforms paid the (now lower) interchange fees on the 80% of debit card volume that were Durbin regulated. They all did it slightly differently: Cash app subsidized it directly, Venmo charged 3% for cards, and PayPal just took margin on commercial payments.

Consumer Banking

Finally, companies like Cash App, Chime, Varo, Sofi and others, all built no fee checking accounts in direct competition to incumbent consumer banks. This opportunity had the most leverage - paid CaC was lower for this opportunity because major banks had withdrawn from most paid marketing channels for this segment, and organic CaC was lower because of new distribution channels like mobile that were underexploited by incumbents. In addition, growing numbers of consumers were extremely distrustful of incumbents because of the predatory reputation of overdrafts. Finally, reliance on legacy infrastructure including on-premise technology and real estate forced incumbent banks to sustain high fixed costs to continue operating, while upstarts grew like weeds on technology stacks that were much more usage driven.

Funding alternative infrastructure

Once the second order effects are taken into consideration, it’s clear that rather than reducing merchant fees, the Durbin Amendment instead shifted a large portion of the overall interchange fee pool away from major banks. Neobanks arose around this fee pool, and in addition to funding these neobanks, it also funded new infrastructure players serving them. The top 5 finance apps in the AppStore all have debit programs issued on top of Durbin exempt banks, and none of them are issued on legacy card infrastructure (they’re all on newer BaaS providers).

The Durbin exempt fee pool has directly funded the development of new card issuing infrastructure including Marqeta, Lithic, Treasury Prime, Unit, Bond, Synapse, Adyen, Synctera and Stripe Treasury among others, as they’re able to participate in the interchange revenue by enabling new consumer neobanks to launch debit programs (and eventually credit and others). This fee pool also supports Durbin exempt banks such as community banks, who were the logical beneficiary of the exemption in the first place. In addition, by enabling these companies to scale, it’s helped fund other infrastructure that neobanks rely on, including account auth (eg Plaid), payroll APIs (eg Pinwheel, Atomic, Argyle) investing APIs (eg Drivewealth, Alpaca, AtomicVest), identity platforms (eg Alloy, Persona) and more.

Regulatory Risk

There have been a few attempts to reverse the Durbin Amendment since it was implemented. The Financial CHOICE Act of 2017[11] was the most prominent. It was passed in the House and never made it past the Senate, and it targeted several elements of the Dodd-Frank legislation, which the Durbin amendment was a part of. Politically I’m not sure what it would take to repeal the Durbin amendment or if it’s right or wrong. Tactically I think there are a few ways it could go.

Everyone is regulated

All debit interchange is capped at 22c + 5bps, with no exceptions. This would benefit merchant processors (Square, Stripe) because their processing costs drop, large merchants (Target, Walmart), digital wallets (Cash App, Venmo) that rely on debit cards to load cards and send p2p, and incumbent banks that are already regulated as it levels the playing field. It would hurt consumer neobanks (Chime, Cash Card, Varo, Sofi), BaaS providers, and community banks dependent on interchange for revenue. Hard to pull off politically as community banks are super distributed and have a really strong lobby.

Everyone is exempt

All debit interchange is set at unregulated rates, with no exceptions. Hurts merchants and merchant processors as their costs rise, and hurts p2p providers who would have to pay more for transactions or speed their transitions to RTP or Fednow, and hurts neobanks as their CaC and retention costs would rise as incumbent banks begin to compete for their customers. Benefits incumbent banks who are already regulated as they now again have access to the interchange fee pool for a large swath of Americans, on top of the overdraft fee pool that they’ve expanded materially over the last decade.

Regulatory interface changes to apply to program managers/marketers

Bank regulators in the US primarily interface directly with banks. This means, for example, that if a neobank did something wrong, and the FDIC was concerned, they’d still spend most of their time with the bank partner that was actually the regulatory entity. It also means that the Durbin Amendment was written to apply to “Issuers”[12]

This subsection shall not apply to any issuer that, together with its affiliates, has assets of less than $10,000,000,000, and the Board shall exempt such issuers from regulations prescribed under paragraph (3)(A).

And only a “bank” can be an “issuer”. As a result, a company that is technically a program manager, issues cards, and is the primary user experience for a consumer (like Chime) can have over $10b in assets, and the cards issued by that company will continue to be Durbin-exempt, as long as that company is not the bank. This is a kind of regulatory arbitrage - eventually there will be companies larger than incumbent banks in terms of assets, that benefit from Durbin exempt interchange.

Neobank exits are complicated

The Durbin Amendment has created a strange dynamic for interchange dependent consumer neobanks in the US; in order to survive, they have to go public. By acquiring Chime, Chase would destroy Chime’s business - either by becoming the bank of record for Chime customers and forcing Chime’s interchange revenue to be subject to Durbin (like the rest of Chase’s debit portfolio), or by maintaining Chime’s cards on the Bancorp, and effectively becoming a decoupled debit program, which is not eligible for the Durbin exemption[13]. This narrows the exit routes for American consumer neobanks, because the most deep pocketed pool of potential acquirers is basically closed to them. As a result it’s quite likely that the ones that survive will be a) formidable competitors, and b) public companies. By the way, I don't think this means they are bad companies - I just think those companies have to capitalize themselves thoughtfully.

A good question for many consumer neobanks in the US is; who will acquire them?

The infra & SMB opportunity for incumbents

All that being said, I think the most promising routes for incumbent banks to benefit from the second order effects of Durbin are via a) financial infrastructure providers and b) SMB focused neobanks. Financial infrastructure providers like Alloy, Persona, Middesk (in identity), Marqeta, Lithic, Unit (in card issuing) and others serve many consumer neobanks, are growing fast, and have business models that don’t depend on nailing consumer adoption. Incumbents could add utility, reduce friction or costs, or drive adoption by building on top of these new infrastructure tools. SMB neobanks have an edge; their interchange revenue is not within scope for Durbin, and they tend to have larger deposit pools on a per customer basis than consumer neobanks. Companies like Mercury, Brex, Nearside, Novo and Found have all benefited from mobile distribution, the added expectation that business can be done online, and the growth of low or variable cost infrastructure providers speeding up their go-to-market. I once tried to open a Chase business account - it took 4 phone calls, 2 faxes and one visit to a physical branch, in addition to applying online. For this reason, I suspect we’ll see an order of magnitude more fintech infrastructure and SMB neobank exits to incumbent banks, than consumer neobank exits.

The long game

To be clear, the Durbin Amendment is not the only reason driving the success of these companies and products. Even if Durbin had never passed, mobile would still be a new distribution channel, and new players would rise and would need modernized infrastructure. After all, the rise in neobanks has happened around the world, not just in the US. Revolut, Monzo, N26 and others all operate in Europe, where interchange economics are so low that they mostly monetize off foreign exchange and other fees. That being said, the Durbin Amendment has been a significant contributing factor, and the profitability of interchange has made a real difference in the strength and heft of American neobanks (vs. European ones for example). Now that these companies have grown up and scaled, nothing stops them from competing with major banks on their most profitable products; is there anything special that makes Chase so good at mortgages, that Chime could never learn? Maybe? But my guess is, companies like Chime and Cash App get good at mortgages and credit cards faster than Chase and BofA shed their branch footprints. I think the longest lasting impact of the Durbin amendment is the emergence of a distinct financial ecosystem that serves probably as many Americans as the major banks do, and will do so for a long time.

Notes

[1] Visa interchange tables here: https://usa.visa.com/content/dam/VCOM/download/merchants/visa-usa-interchange-reimbursement-fees.pdf

[2] Overdraft Revenue Begins to Rebound

[3] In practice, the subsidy often went the other way, with fees from low balance customers subsidizing richer consumers.

[4] The pandemic has really laid bare the true liability of branches. In March and April 2020 as much of the country locked down, there was about ~3 weeks during which no one could enter a branch. When 100% of financial activity shifted online, mobile first companies really benefited, and legacy banks still paid rent on branches. In person activity still hasn’t returned to pre-2020 levels, but banks still pay rent on branches. One additional confounding factor; banks have to navigate some political minefields when closing branches - the loss of financial access and jobs, particularly in remote or rural areas that are underbanked irks elected officials, so banks face enormous friction when they try to close branches.

[5] Forbes: Top 10 Most Downloaded Apps And Games Of 2021: TikTok, Telegram Big Winners

[6] Wikipedia: Zero Interest Rate Policy

[7] Bank Profitability and Debit Card Interchange Regulation: Bank Responses to the Durbin Amendment

[8] OVERDRAFT PRICE RISES TO $30 PER TRANSACTION

[9] ChexSystems, Inc

[10] https://www.congress.gov/bill/115th-congress/house-bill/10

[11] https://www.law.cornell.edu/uscode/text/15/1693o-2

[12] Federal Reserve Releases Final Rule to Implement the Durbin Amendment

[13] Over 4 Million Move Their Accounts From Wall Street Banks in 2010

Thanks to Aaron Klein, Justin Overdorff, Amias Gerety & Jim Esposito for reading this in draft form.

Regulated industries often run on “documentation”.[1] A simplified, non exhaustive way to look at this is that for each “transaction” (or customer interaction), the organization has to 

• Collect Information Step: collect certain information from counterparties (customers, vendors, partners etc)

• Rule Validation Step: validate that information against a set of rules, 

• Real World Reconciliation Step: Reconcile that information against something in the real world, 

• Signature Step: ensure the correct, authorized individuals sign certain documents (consents, terms and conditions etc)

  • The signers are typically taking on some kind of authority (clinical, statutory, fiduciary etc)

• Ongoing Monitoring Step: Ensure that on an ongoing basis, the behavior of each counterparty complies with 

  • What they agreed to at the start

  • Various statutes and regulations they’re subject to

• Exception Step: Take certain steps to fix exceptions 

  • And document that those steps were taken, and when, and any resolution

You can think of a “transaction” as the atomic unit of value a business provides. For a bank, a transaction might be opening a deposit account, opening a savings account, approving a loan, etc. For a healthcare company a transaction might be seeing a patient, submitting a claim, prescribing medication, etc. A customer relationship can span multiple transactions. In a regulated industry, for most mature transaction types, the required documentation is generally specified by law/regs, and relatively standardized (or otherwise within a reasonably narrow bound). 

Compliance is (colloquially) the function that ensures that the right information was collected, the right items were validated, the right monitoring is in place on an ongoing basis, and the exceptions were properly handled and documented. Audits are typically adjacent to compliance, and often involve sampling a number of transactions and reviewing the documentation collected.

Some examples:

I’m not as familiar with regulated industries other than healthcare and financial services, but my intuition is that the paperwork burden in energy, insurance, real estate, etc rhyme with the framework I’ve described above. One way to think about a lot of the paperwork/documentation is that the institution is converting information that is unstructured and/or received in a wide, broadly unpredictable variety of forms, into enough structure that it can be compared against a set of rules or policies. The institution then uses these rules to decide whether to enter into the relationship, how to price it, and so on.

As it turns out LLMs are good at turning multimodal unstructured data into a variety of structured forms (and vice versa). Some examples of this that I am extremely familiar with either because I directly helped build or have invested in these companies/products:

1. Carbon built tooling to extract visit intent from patient phone calls, report that to clinic managers, & drive visits

2. Abridge and the Carby AI scribes convert voice recordings of a patient visit into a chart and medical codes

3. Recon Health converts payer contracts into a) contracted rates so providers can know how much they will actually get paid and b) payor rules so providers know what to do to stay out of trouble

4. Inscope’s Report builder converts financial data into financial statements, footnotes and disclosures for private company filings.

5. Charta Health converts clinical documentation into auditable format

6. [I know this less well]. Abel converts police body camera footage into police reports

A general way to think of “documentation” in these industries is “proof of work” vs. “proof of thought”. 

Proof of work

Some types of documentation prove that you operated according to the rules. You can think of these as “proof of work”. Typically this documentation has a relatively standard format and is required. It’s audited on some cadence. The way to know that some kind of document is proof of work is whether it is default used as evidence when something goes wrong or when there’s a lawsuit. Medical records in healthcare and CIP/KYC data in banking are obvious examples. When something goes wrong with a patient, the medical record is the artifact that’s used by clinical leaders, auditors, lawyers etc (depending on the problem) to check if the patient received the standard of care and the clinicians did the “right” things. 

This type of documentation occurs much more frequently in regulated industries (or in heavily regulated parts of every industry, like HR or workplace safety). It is here to stay, will only really change when regulations change, and LLMs ultimately make these easier to generate, to audit, and make sure the documentation and the operational process they’re meant to document are actually occuring. The canonical example of this in healthcare is AI Scribes being used to generate chart notes/visit summaries. Visit notes are typically in a fixed format, and historically had to be generated by doctors (who are very expensive) by hand. AI scribes can generate a more complete version of a visit note, in the correct format, just from a transcript, with much less effort than a doctor could by hand. Over time, the burden of generating this type of paperwork is going to go away. 

Proof of thought

The other major type of documentation is more about enabling a discussion and  supporting a decision. These are meant to help the writer and the audience make high quality decisions, and prove that the writer was thoughtful about the different scenarios and edge cases the organization might face in executing on some decision . They’re not standardized, and they’re barely (if ever) audited, and once you arrive at the decision, you rarely return to these documents. These are things like product requirement documents (PRDs), RFCs & business memos. 

This type of documentation is really at risk, mostly because artifacts that used to mean that the author(s) had holistically thought through the problem, no longer dependably signal that the writer was thoughtful. A memo about a decision can now easily be generated by a consumer grade LLM, and in skimming it you would miss that the writer might not have thought through the decision as well as you (the audience, or the leader of the organization) would have expected them to. In proof-of-thought cases, downstream of an LLM generating text is a human who must synthesize meaning from it, critically think, and ensure it was prompted properly, and reflects the real risk that specific organization is taking in the real world as it goes about it’s business. As the cost of generating a lot of reasonable sounding text drops to zero, the downsides of a) the audience skimming and b) the organization relying on proof-of-thought artifacts rise exponentially. 

Almost perversely, the emergence and improvement of LLMs & multi modal models you can chain together will likely result in opposite effects for proof of work vs. proof of thought documentation. 

Proof of thought documentation will likely become less and less reliable over time, and organizations will have to develop antibodies to reduce the odds that large slugs of reasonable sounding text that are devoid of meaning infect their decision making processes. 

Proof of work documentation will likely get better and more complete, while the associated drudgery/tedium goes down. I think over time, the nature of white collar “work”, particularly in these regulated industries, can migrate from generating, managing and auditing paperwork, to ensuring that the real world outcomes the paperwork is supposed to produce, are actually produced, reduce the occurrences of exceptions (deviation from rules or policies) in real time, and ultimately match the institution/organization’s stated objectives. 

1. It’s likely lots more industries run on documentation, I’m just much less familiar with the purpose, why it exists, what its used for etc.

In the weeks and months around the conference we got to meet several leaders & founders building and using stablecoins at work. This recap is an attempt to synthesize some observations and learnings. At a high level some key takeaways from the talks are below:

A majority of stablecoin demand is from overseas

Globally, demand for USD dramatically outstrips supply. Given that, it’s not surprising that 80% of Bridge’s demand comes from overseas. It’s also not surprising that there aren’t many examples of mainstream F500 brands utilizing stablecoins in production today. 

But overall, the demand for stablecoins roughly reflects outsize demand for dollars (both from consumers and businesses outside the US, and from digital asset users as a settlement currency).

Regulatory clarity is coming

The text for Governor Waller’s talk is here: https://www.federalreserve.gov/newsevents/speech/waller20250212a.htm

Two points stuck jump out. First, regulatory clarity is coming:

“The stablecoin market would benefit from a U.S. regulatory and supervisory framework that addresses stablecoin risks directly, fully, and narrowly.”

In addition to the signaling of a Governor of the Federal Reserve making embargoed remarks at a stablecoin conference, it’s super encouraging to see that policy makers are thinking about a regulatory regime specific to stablecoins, that addresses stablecoin specific risks (as opposed to layering the regulatory regime for banks onto the stablecoin market).

Second, regulatory fragmentation might also be coming:

“Fragmentation in regulation also has the potential to hold stablecoins back from reaching their full potential. As I already discussed, the stablecoin market does not have a clear regulatory framework in the United States. While there have been efforts to develop some international standards, the emergence of different global stablecoin regulatory regimes creates the potential for conflicting regulation domestically and internationally.7”

What this ends up meaning operationally for different stablecoin issuers in different geos still waits to be seen, and curious what the enforcement mechanisms will be. For instance, how does a stablecoin issuer comply with different reserve requirements in different gets? In general, the pragmatic approach Governor Waller outlined is super encouraging for what’s coming down the pike regulatorily.

There’s real enterprise interest in stablecoins, but not much real enterprise adoption (yet)

Several speakers/panelists called out that lots of enterprises and institutions were exploring how to utilize stablecoins. Given the obvious advantages there are 2 big hurdles left to cross:

• Regulatory clarity: unsurprisingly, the largest brands in the world, have the most to lose. Regulatory clarity on how to utilize stables, what criteria to use when selecting, and what use cases are sanctioned. In the time since the conference, the evolution of the GENIUS Act, combined with banking regulators like the OCC clarifying positions around crypto, and the various summits around crypto indicate that some regulatory clarity is on the way.

• Liquidity: even today, lots of stable to fiat trades happen in group chats over WhatsApp and signal, and moving large sums require working the trade. Lots of folks have built bots to automatically respond and handle incoming messages so they can get liquidity. This is the definition of an OTC Desk (and lots needs to happen for this to scale).

There will (likely) be many stablecoins

Governor Waller called out competition and low barriers to entry as key attributes for developing a vibrant stablecoin ecosystem. At least a half dozen speakers and panelists on stage either directly issue stables or have in house capacity to issue stables; m0, USBC (with deposit tokens) Brale, Bridge, BVNK, Circle & Paxos). These issuers represent everything from startups to scale and every thing in between, and new stablecoin issuers (and stablecoins) emerge every day. 

You can buy a Ferrari with USDC

BVNKs Ferrari use case & Stripe buying Bridge both clearly indicate stablecoin acceptance at the point of sale is coming to retail payments. What’s not yet clear is how quickly or slowly retail adoption will follow. But merchants and acquirers are showing increased interest in utilizing stablecoins in production.

Stablecoins are coming for (or to?) banks

It’s clear banks have a role to play in the stablecoin future. It’s less clear what that role will be. Banks like Lead and others have already provided support for stablecoin issuers (and access to fiat rails) for years. Efforts like USBC will enable banks to deploy deposit tokens (ie a stablecoin with all the attributes of a deposit, including being fractional, having FDIC protection, Reg E protection etc). 

Governor Waller called out that it’s fairly logical for banks to be able to issue stablecoins (in addition to issuing deposits). I’d be surprised if whatever ongoing legislative/regulatory/policy approach did not allow for banks to participate in stablecoin issuance. Even the GENIUS ACT alludes to this:

One last, broad takeaway (not specific to the conference). Americans (and westerners in general) who work in payments have a unique blindspot around stablecoins (and by extension around blockchains in general - more on this later). From what I can tell there are 2 current driving forces for the current phase of stablecoin adoption: 1) digital assets needed a settlement currency and 2) non-US consumers and SMBs needing access to dollars for payments, for savings, for currency stability etc. The corporate treasury and enterprise use cases definitely lag these two in adoption. 

The leaders in payments in the US, literally do not spend any meaningful time on either of those 2 problems. There is probably no living American who works in payments that has experienced an unstable/volatile/hyperinflated USD. In a lot of cases these folks aren’t even skeptical of stablecoins, they’re almost indifferent. For the most part stablecoins don’t (yet) solve problems in their day to day, and at least until recently, have not had enough scale in the contexts that move the needle for them. So they don’t pay attention to them. This is starting to change, but is my current best explanation for why enterprise adoption has lagged. 

All in all - the gathering was a roaring success. Thankful to everyone who came, and looking forward to Season 2.

Thanks to Kerry Kellogg for reading this in draft form.

In the beginning the internet was small, and users were few, and everyone knew where everything was. Then the internet got too big, and you needed a search engine to find what you were looking for. And the internet felt small again. Now again, the internet is so big, that even search is not enough. So along came Deep Research.

Deep *X*

From what I can tell, the “AI Agents” that are in most widespread use today are “Deep Research” agents; Google, OpenAI, Perplexity, Manus and several others have one. Coding agents are probably second. Both of these examples agents typically complete a non-deterministic task (a task with subjective output/no correct answer). 

I’d spent some time with a couple of founders building agents for shopping and I didn’t really get it initially. Most recently I’ve been trying Deep Research out with a handful of holiday shopping tasks and I can’t tell if there’s something there but it feels like “Deep Shopper” or “Deep Concierge” is a(t least one of many) logical evolution of Deep Research given what it appears to be good at (assembling many options and synthesizing them into a single view faster/with less effort than you would manually). I’ve long believed that most ideas (at least at inception) are bad, and I’m just not yet sure the way in which this is bad yet.

Deep Shopping

Think of this as “Deep Research for Shopping” and it can deliver a few specific benefits:

1. Saves you (the shopper) time: imagine buying something you don’t regularly buy. This could save you the time and energy you’d use to research it, and bring you back a set of options with an articulation of the various benefits and tradeoffs of each

2. Saves you money: once you’ve selected the specific option you want, this agent can find the specific outlet online with the best price (eg Amazon vs. Nike for shoes)

3. Configuration: imagine trying to find a holiday house for a large group of people - in some cases it’s actually cheaper/more feasible to find two houses next to each other. If you have a big family that gets together a couple of times a year, you know this pain intimately. Most platforms make this harder to do than it should be, and this agent could help you optimize across platforms as well.

4. Exceptions: finding you the most fastest shipping, and most favorable cancellation and return/exchange policies

5. Qualitative evaluation: this is something like aggregating Reddit reviews and finding potential issues that a) you wouldn’t know existed and/or b) you wouldn’t realize are important to you.

These benefits are all about the shopping task. A meta benefit this could deliver is more about the shopper: normalizing results into a single aggregated view that makes them easy to compare by generating the UI directly, and making the UX completely custom to the shopper’s revealed preferences.

And at the end the agent could allow you book directly or present a buy button and complete the task for you. The company who builds the agent could issue a card to complete the transaction which would simplify credential handling in the short term while agent specific payment primitives mature. 

Start Extremely Narrow

This feels like the kind of thing where most people will start wide/general, and I think starting narrower with either an extremely high frequency shopping task, or a low frequency + high value shopping task is better. 

My reasoning is that shopping is a slightly more deterministic task than knowledge acquisition (the Deep Research use case) and in many cases once you’re consuming the object you bought it is EXTREMELY obvious if it was wrong or off in some way, and in the higher value cases the point at which it’s obvious you made the wrong choice, is also the moment it’s hardest and most expensive to reverse (staying on the holiday house use case - by the time you’ve realized you booked a crappy Airbnb, you’re already in it).

As a result, I believe it’s better to create a shopping agent that is absolutely excellent at one task and can so consistently get better results than a human would, that humans who do not use it are at a material disadvantage. And once you’re excellent at one, it’s easier to become excellent at others (vs creating something general and trying to be good at everything).

Monetization

This feels reasonably obvious but I’ll state them anyway

• Ads: an agent that is 2x - 10x better than the average human at a shopping task has incredible real estate to surface sponsored results. Even better if it has differentiated understanding of that users revealed preferences.

• Affiliate fees: obvious monetization in lots of shopping categories.

• Transaction fees/interchange: Lots of ink has been spilt on agent payment frameworks. A simple short term path would be to issue the agent a payment credential of it’s own. This allows the user to pay only when they’ve authenticated against a specific purchase, without handing over their own credential for further use.

• Percentage of savings: who doesn’t like free money

Open Questions

Just a few that come to mind:

1. One of my favorites: what happens to chargeback rights when the purchase is completed by a machine? Right now consumers win ~¾ of chargebacks and merchants win the rest. Does this change? Does the agent take financial responsibility?

2. More generally, who bears responsibility for errors? The user? The agent? The company that made it?

3. What is the final configuration (or set of configurations) for payment instruments? Will we live in a world where each person has many agents doing things for them, or will we generally have a single agent that can do many tasks? How does authentication work in all these scenarios?

4. Merchants have invested a ton in e-commerce experiences; is there incremental investment required to make those experiences agent friendly? How will merchants react to consumers buying from inside an agent experience?

5. Many merchants have also invested heavily in bot detection for blocking purposes - whats the mechanism for distinguishing between bots that might result in a legitimate sale vs. spam.

To patch this gap, I’m organizing a one day-conference on stablecoins with my good friend Aaron Frank where practitioners from the stablecoin world will meet finance professionals across the CFO Suite, Corporate Treasury, Payments and the Correspondent Banking universe. The invite-only event will take place in San Francisco on Wednesday February 12, 2025. Confirmed speakers include:

• Jeremy Allaire, founder & CEO at Circle

• Jackie Reses, founder & CEO at Lead Bank

• Neetika Bansal, Business Lead for Money as a Service at Stripe

• Zach Abrams, founder & CEO at Bridge

• Cuy Sheffield, Head of Crypto at Visa

• Ronak Daya, Head of Product at Paxos

• Sigal Mandelker, Partner at Ribbit & previously Undersecretary for Terrorism & Financial Intelligence at the US Treasury

With more to come. If you’d like to attend please sign up here. And in particular, if you run a financial payments or treasury function at a non-financial company, I’d love to hear from you.

If you believe that the long term adoption of stablecoins (and crypto in general) will come from existing crypto users, this is not for you. I believe that dramatic adoption of stablecoins will come from large enterprises and financial institutions a) moving their existing fiat workloads (work flows? Money flows? Not exactly sure what to call this) onto stablecoin infrastructure and b) unlocking marginal use cases that were simply not possible in fiat-space. If you buy this fiat > stable thesis, then this conference is for you. Today, there are heads of payments, finance, and treasury at very large non financial companies, who don’t yet realize that they can use stablecoins to achieve their business objectives better, faster and cheaper. We created this conference to enable these leaders to meet folks building the stablecoin products for them.

– 

I’ve written here and here about the myriad problems that stablecoins can help solve. And their ability to flatten time-to-money for transactions around the world is really exciting. At the conference we’ll explore several institutional and enterprise use cases that move trillions of dollars worth of value each year, and that could benefit from stablecoins along a cost, speed, operational or experience axis. How to reap these benefits is precisely what we'll discuss at the conference. Examples of these use cases are below: 

People around the world can now save in dollars

For decades, wealthy elites in poor countries have held excess savings in reserve currencies (GBP for much of the last 200 years, USD and EUR more recently) as “stable” stores of value. frequently the strategy was to hold a mix of liquid (securities) and hard assets (eg real estate in downtown London). With stablecoins anyone (and in particular, folks on the low end of the economic spectrum) in any of these countries can now save in a “stable” currency, with relatively low fees and transaction costs, regardless of their wealth level. 

This is pretty transformational: in most countries you need to transact in the local currency,  but it previously wasnt possible to save in non-local currency at any scale. Now it is.

• Consumer products enabling this: AirTM, Dolar, Chipper Cash, Parallax, Sling Money, Littio, Belo.

• SMB products enabling this: Dakota, Brale

• Infrastructure enablers: Brale, Bridge, BVNK, Hifi[3], and Portal[2,3] 

I’m sure there are others - if you’re building one of these I’d love to learn more.

Launch Globally on Day 1

The last 2 generations of digital wallets (like Paypal in gen1, and Cash App and Venmo in gen2) launched as US-first products before stablecoin infrastructure existed. While Paypal figured out how to go global over the last 20 years through a combination of acquisitions and integrating with local infrastructure around the world, Venmo and Cash App have remained constrained to the US (with very small footprints outside). With stablecoin infrastructure, money products can launch globally on day 1 with USD balances (held in an stablecoin instrument like USDC) available to all users, and instant money movement in and out of the US. 

By providing USD balances to KYC-ed consumers around the world, digital wallets like Cash App and Venmo might have been able to reach global scale without having to invest in local stored balance infrastructure in each country. That being said, most markets now have local p2p and digital wallet champions so the novelty ship has sailed. What has insane demand and hasn’t been totally captured yet? The ability to save in US-backed stablecoins, from a company with a material, trusted brand. [1]

I think the current best example of this globally is what the team at Sling money is doing, but I’m sure there are others. At an infrastructure level, providers like Bridge and BVNK are enabling this. 

Correspondent banking & Global Treasury on stables

In general terms, correspondent banking can be defined as “an arrangement under which one bank (correspondent) holds deposits owned by other banks (respondents) and provides payment and other services to those respondent banks”. A simplified model for correspondent banking looks like this:

• Bank A in Indonesia holds deposits at Bank B in the US

• When a customer of Bank A wants to pay a recipient in the US (or move money between it’s internal accounts), Bank A instructs Bank B to initiate the payment to the recipient’s account and routing number (this might happen via wire or ACH deposit)

• Later, Bank A “tops up” their “account” at Bank B.

Stablecoins can be a modern, fast alternative to correspondent banking. A simplified model for a stablecoin alternative might look like

• Bank A in Indonesia holds USDC somewhere (eg at Circle, or in a self-custodied wallet)

• When a customer of Bank A wants to pay a recipient in the US, Bank A onramps to USDC, then uses a service like Bridge to initiate the payment to an endpoint of the recipients choice (account +  routing number, card, or wallet address of the recipient’s choice)

• [No third step]

Relative to traditional correspondent banking, this can happen in minutes, be initiated 24/7/365 and is self reconciling (as it’s on-chain). This is simultaneously a better end-customer experience for both the sender and the recipient (so Bank A’s customer can initiate the payment at any time and ensure the recipient receives it in real time), and likely cheaper from a transaction cost and net working capital perspective. Going one step further:

• Bank A in Indonesia holds Rupiahs

• When a customer of Bank A wants to pay a recipient in the US, Bank A mints a stablecoin of their own, then uses a service like Bridge to initiate the payment to an endpoint of the recipients choice (account +  routing number, card, wallet address)

• [No third step]

Similar to the second simplified model, with Bank A maintaining control and continuing to earn yield on the payment amount if the recipient accepts the payment in a wallet address. This modern alternative is possible and available today.  

For the largest companies in the world, who bank with the major multinational banks, and do significant volume, they will often have a function internally that actually trades FX and interfaces with the FX desks at their banks. They get fairly tight FX spreads and don’t really have problems with liquidity. Smaller companies and SMBs, however, who have lower volume and/or transact less frequently, often pay a tax - either in speed to trade or wider spreads/commissions, as they will often use tools built more for consumers (like Moneygram or Viamericas) or more recently services like Wise. Even then, all these customers (large and small) don’t have access to 24/7/365 crossborder money movement. Most don’t even realize the working capital impact it could have to not have your money trapped overseas for 2/7th of the year. Outside of rates, transaction costs, and speed, stablecoins also make money movement available literally more of the time. My favorite recent example of this is SpaceX utilizing stablecoins to move from Argentine Pesos to USD, using Bridge: https://x.com/AutismCapital/status/1870291626230460846

The second part of the innovation here is that correspondent banking is still very much a relationship business. Moving to a stable coin based infrastructure enables even small banks around the world to directly themselves or enable their customers to remit payment around the world without having to form a relationship with a bank in the destination country. Correspondent banking for a large entity like Citibank is very much solved. For smaller banks doing longtail of currency pairs, it is absolutely not. Some companies working on this are Sphere and Connect.

Low cost, instant payments worldwide

Many countries now have instant payment rails with reasonable adoption(e.g. Pix in Brazil, UPI in India, Fednow/RTP in the US). However, moving money around the world, even between these places, is rarely instantaneous. 

Stablecoins makes these rails interoperable. If you’re a crossborder payment service, you can now provide your customers real time payments across remittance corridors (and likely more coming soon) by chaining a local instant payment rail with stablecoins in-between:

1. PIX > USDC > UPI 

2. UPI > USDC > Fednow

3. RTP > USDC > PIX >

Here’s how this might work:

Essentially there’s an opportunity to build a new global instant payment network for enterprise use cases that looks like chaining local instant rails and adding new ones as they come online.  

If you’re a multinational operating in these markets, the combination of correspondent banking infrastructure built on stablecoin infrastructure and low cost instant rails around the world mean that you can repatriate funds much more meaningfully and quickly than was historically possible, and in many cases without a bank intermediary. 

This kind of rhymes with what the team at Connect is doing, but havent seen much about it (despite how large I think this can be). If this is you, I’d love to learn about your approach.

Payouts

Many companies are being built around the opportunity to compliantly pay workers around the world. These include traditional payroll providers like ADP and startups like Gusto and Remote.com.[2] This feels fairly solved (as in I’ve seen many companies offering this service), but I anticipate that employers around the world will need their tools to appropriately handle cases like deductions, tax reporting to local authorities and more. 

Barriers to Enterprise & Institutional Adoption

If you believe in a future where large corporations and institutions around the world utilize stablecoins for payments, treasury, and foreign exchange, many things still need to be built to enable that future.

A large enterprise can now quite easily experiment with stablecoins. However, moving a core activity onto stables at scale in an automated way requires reconciling to the enterprise's systems of record with good exception handling. Otherwise, whatever savings on transaction cost, speed, or net working capital can easily be subsumed by expensive human bandwidth needing to handle exceptions. Some of the areas that are top of mind and example questions that are solved reasonably well today in meatspace)

• Accounting: how do onchain transactions get into Netsuite (or pick your ERP of choice), rolled up into monthly/quarterly close, and ultimately into financial statements

• Reconciliation: how are financial activities tied to operational ones?

• Payments: how do suppliers/vendors specify payment instruments? How are exceptions handled (eg what happens when you send a large sum to the wrong address? In the card and ACH world, a lot of an enterprises assumptions about how to handle exceptions are based on the ability to dispute transactions. What happens when these transactions are onchain and truly irreversible? what happens if someone fat fingers an address and a large sum goes into the ether?) How are they investigated + resolved?

• Foreign Exchange & Liquidity: how deep are the orderbooks in the currency pairs that matter to the firm? (the shallower they are, the more expensive they are to transact in). I’ve seen at least one case where an early adopter enterprise wanted to move $3m from Argentine pesos to USD via USDT and it took several days to work through the order. This amount is trivial from a fiat FX perspective and without fixing it, it’s just gonna take a while for enterprise adoption to take off.

If you’re building solutions to any of these barriers, I’d love to meet and learn about how you’re going after it. I anticipate that the largest companies will start adopting stablecoins very gradually, and that the steady state will mix fiat and stablecoin-based transactions, with companies making decisions based on the best mix of price, speed, liquidity, and operational ease. If this is true, will existing tools extend functionality to treat stables as another currency type or instrument? Or will brand new tools get built from scratch around stablecoin/ hybrid infrastructures? 

What tooling doesn’t yet exist?

Everything described above already exists and is already happening at a small scale. I believe they’ll only grow in volume. For that to happen; for financial institutions, enterprises and consumers to trust stablecoin infrastructure with ever larger sums of money, new tools need to be built. This is for everything from:

• Know-Your-Customer programs: what's the default mechanism that financial institutions trust to ensure that the end-holder of a wallet is not on the OFAC SDN list? The USBC approach (new permissioned L2 + privacy preserving identity verification) feels like what will eventually need to happen, but there are probably other approaches out there

• Exception Management: Fraud, risk and risk operations in a world where payments no longer flow only on weekdays, and more. Even the regulatory playbooks around these innovations probably need to change. 

• Reg E (and Reg E equivalents): local payment schemes often have well defined, regulatorily driven consumer protections. Stablecoins do not yet (and the odds are these won’t spontaneously develop through market forces). 

• Currency visibility & controls: monetary authorities have a set of tools that (mostly) assumes fund flows and foreign exchange are in fiat. Central banks and treasury departments will need tools that distinguish between local currency being used to buy $FARTCOIN vs being used to buy USDC, at a minimum to understand actual exchange flows, but probably also for anti money laundering etc.

These kinds of tools are mission critical for enterprise adoption and making regulators comfortable, and represent one of the most fertile areas to explore. Similarly to above, if you’re solving these problems, would love to chat.

One more policy + regulatory thing I’m pretty interested in learning about (I genuinely have no idea who is knowledgeable about this so if you are, please reach out) is what it means geopolitically to make USD available to people around the world.

• If you’re Australia, are you worried that your citizens will start saving in USD (via USDC?). Are you worried about what that does to Australian Dollars? (or any country’s local currency?)

• If US consumers and SMBs start saving in stables as a way to earn more interest on balances, does that drain deposit capital that would otherwise be available for maturity transformation in the US banking system? How does the US weigh the costs of this effect vs. the benefit of more demand for US Treasurys (and the concomitant lower borrowing costs for the US/reserve status (have written about this before but I think this effect is only going to be more pronounced)

• Blockchains make transactions far more traceable, so if you’re the US Government, do you support the movement of USD onchain because it enriches financial crime forensics?

• How does the US weigh the net impact of higher demand for dollars increasing the strength of the dollar in general, vs the negative impact on US exporters?

• Who's doing SAR filings on USDC accounts (or the equivalent)? Streaming payments via stablecoins (think of several microtransactions per second) would almost certainly break/defeat most bank’s monitoring infrastructure

• How much non us citizen/retail usd demand is true long term savings vs everyday spend and what’s the implication for duration/maturity transformation

• If you’re a medium sized corporate in Indonesia (or any country with meaningful demand for usd) and you could manage your treasury in usd, would you do 0%, 20% or 80%?

• If a stablecoin emerges that exists entirely within the US regulatory perimeter and essentially looks like checking account capital from a bank‘s perspective then over the long run is it reasonable to assume it will have a similar duration profile as checking accounts for US citizens? Or would we still consider it “hot” money (or super low duration)?

• What’s the net impact of stables on US funding/treasurys? Are they just mega amplified demand for TBills (or the front end of the yield curve in general)?

These are all written from a US centric perspective, but for every country with the same dynamics (it won’t be the US forever) the same questions apply. More broadly, A Very Stable Conference will be an opportunity to explore these topics and more. You’ll get to learn from a mix of practitioners already building these tools, early adopters who are using them, and scaled enterprises as well financial institutions who will eventually become adopters of stablecoins. Again, if you’d like to attend please sign up here. 

Thanks to Jim Esposito, Zack Rosen, Kerry Kellogg, Cuy Sheffield, Nico Chinot, Brandon Carl, Temi Omojola, and Aaron Frank for reading in advance.

[1] This makes me question why Venmo hasn’t launched with PYUSD yet. 

[2] In full disclosure I’m an investor in Bridge, Portal, Lead Bank, and Remote.com

[3] I think the programmable wallet + bank account instrument infrastructure differs slightly from the other infrastructure enablers as it enables an end user/customer to define behavior that works for them on a continuous basis (eg every time I get USDC at this wallet please convert it into dollars automatically)

As adoption has expanded over the last half decade I’ve grown increasingly curious about how more traditional (non crypto, and in many cases non-financial) institutions could solve problems using stablecoins. While I’m insanely interested in learning more about this topic, I’ve found stablecoin-related conversations are often too centered around crypto use cases, organized for crypto-native audiences, or too high level and removed from practical considerations faced by potential customers, especially at the enterprise/institution level.

To patch this gap, I’m organizing a one day-conference on stablecoins with my good friend Aaron Frank where practitioners from the stablecoin world will meet finance professionals across the CFO Suite, Corporate Treasury, Payments and the Correspondent Banking universe. The invite-only event will take place in San Francisco on Wednesday February 12, 2025. Confirmed attendees include leaders from Visa, Expedia, Youtube, Lead Bank, Coinbase, Circle, Block, Paxos, Bridge.xyz, Brale.xyz, Modern Treasury, Monzo, Wise, Ribbit, Bain, Paradigm, Portal, Colosseum, QED, HiFi, Agora, AWS, Lightspeed, Sphere, Bitso and more.

If you’d like to attend please sign up here.

The focus is practical and actionable discussion on how enterprises and institutions can deploy stablecoins in their business today. More to come on topics & programming.

[1] In full disclosure I’m an investor in Bridge.

The basics

Today’s password managers already do a good job of storing and retrieving usernames, passwords and (recently) MFA for human users. I’ve mostly used 1Password, and I find their browser UX to be fairly slick. But their tooling for developers building agents or RPA[1] feels like an afterthought. 

Simply making it possible to easily access token based authentication via an API would be phenomenal, but looking through their docs this isn’t really well supported unless you’re willing to spin up your own service. However, without some tooling for this, you can’t really utilize RPA or AI agents in trusted environments, and its even harder to have automations run in the background.

The edges

Once you have something that enables basic password management and 2FA, there are a ton of edges that current tools don’t handle at all. As a result, particularly for high volume use cases, you’ll kind of need a human to babysit. 

Handling all MFA methods & backups

There’s no standard way for enterprise webapps (think of this as any web application built by a 3rd party, that business users have to use in their day to day) to handle MFA & backup codes. Google is way ahead of the curve; GMail and Google Workspace allow users to configure multiple mechanisms for signing in, including multiple types of MFA and recovery mechanisms.

In addition to this Google is one of the early adopters of Passkeys. I personally can never really tell which login model I’ll need or be able to use when I’m logging into a Google app on a new device, but you can tell it’s somewhat thoughtful. I think in future, enterprises (and their security leaders) deploying any kind of browser automations, whether they be bots or agents, will simultaneously need services that can handle all these methods for their bots or agents  in a tier 1 way, and enable them to have high quality visibility into how these credentials are being used.

In practice, in the context of bots and agents, I *think* this means that we should think of the password manager for agents as a password manager + authenticator + email inbox + sms inbox. In healthcare, I’ll use Cigna’s provider interface as an example (https://cignaforhcp.cigna.com) the auth model includes

• A username 

• A password

• One time passcodes sent over email

Even if you could have your AI agent utilize something like 1Password or Lastpass, you’d still need a human monitoring the email inbox every time your agent needs to log in. If a password manager could programmatically generate an inbox specifically for this, that was bounded to your enterprise domain, this problem’s mitigated. This model could also handle magic links (similar to passing along a one time code, just passing along a sign-in URL).

Doing this creates another issue - what happens if Cigna starts sending OTHER (non MFA) notifications to that email address? I *think* these are easy/okay to forward on to a human/group inbox, and setting up forwarding at least means your automation doesn’t break simply because the person in charge of monitoring it took the day off. [2]

The same dynamic is true for phone numbers, and from what I understand, lots of sites have constraints that prevent users from setting up sms based 2FA using VOIP numbers. I think in this case the innovation is to actually be able to a) generate non VOIP numbers that can be used and b) monitor the message inboxes for those numbers when one time passcodes come in. In addition, the telephony restrictions mean there will need to be a physical deployment component, as provisioning non-VOIP SMS-capable phone numbers will typically require hardware and at least 24-48 hours of lead time. You could probably reduce this lead time with some clever BD with the telephony operators (eg Verizon). However, this physical device constraint is one reason why this functionality makes sense for a 3rd party password manager like 1Password or enterprise auth provider like Okta to build.[3]

Tracking

The other pretty material thing you’d want is to be able to log 

• All agent sessions

• Anytime the vault was accessed by a human (or by an entity that is not the agent the vault was designed for)

• Any logins/activities/sessions with behavior that deviates from what the agent was designed to do

This is kind of similar to the audit trail functionality that exists in SSO products like Okta, with the added layer of intelligence that its likely your agents will be executing at such high volumes, that the most interesting thing is your security team will want is insight into anomalous behavior - both when a non-agent is utilizing the agent’s privileges, and when the agent is doing things it shouldn’t. 

Why is this all necessary

In an ideal world, every webapp/portal out there would be like Google and use passkeys. In the world we live in, enterprises (and any automations they deploy) will need to interface with aged portals built by underfunded teams, and this will be true for a long time. As such a modern authentication platform will have to be backwards compatible, with all the varying security paradigms enterprise apps have deployed over the last 2 decades.

Assuming this works (or something exists that serves this purpose) there’s an additional layer of authorization or permissioning that might need to be built. If you model an agent as an executive assistant or personal assistant, you can let it largely be autonomous, but request permission from you under certain general conditions (eg ask before spending more than $300). Not super sure whether this permissioning layer should be centralized (ie I have one area where I manage all my permissions), embedded (ie in the agent control surface area) or just via messaging/sms. But it will need to exist, and is a natural extension of the authentication layer.

How you’d build this

The fullstack way to build this would be to build a password manager from scratch. A “lite” version would be to wrap something around an open source password manager like KeePass. The main benefit of the fullstack path is you have full control, and can ensure a consistent high quality experience to all end users + buyers. The main downside of this path is; to build a high quality, performant password manager is probably quite expensive, and the odds of screwing it up rise exponentially if you’re doing it from scratch. In addition, no enterprise will trust you for a very long time.

The path I think makes the most sense is to build a layer that sits on top of corporate/enterprise password managers (like Okta, Bitwarden, Passworks, 1Password etc). This way, the enterprise maintains control over their core password management system (which is probably deeply integrated into their security/IT stack), and can give you access to a vault for their bot or agent workflows. Assuming the APIs are good enough for entering, managing and retrieving credentials, and for the session logging/tracking, this would work just fine, and enables you to focus on safely handling credential access (vs. storing, enterprise sale, etc). I’m just not yet sure if the developer access for these services is there yet. And lastly, if you screw up or anything happens with those credentials, the enterprise can easily revoke your access.

I started down this path from exploring authentication for AI agents, but in the process have realized that every Robotic Process Automation (RPA) service would heavily use similar tooling. In doing a pretty extensive investigation and talking to several companies doing RPA, their default solution to this problem is to ask customers to turn off MFA. . .

Open Questions

Having not built security products in the past I can’t tell if there are fundamental, first principles things I’m missing for why this doesn’t exist. The questions in my mind are:

1. Does having your password manager handle SMS leave you somewhat vulnerable to socially engineered phone number switches at the phone carrier?

2. Is there a similar attack vector for email?

3. Are enterprise bot/RPA/agent use cases high volume enough that something needs to exist to handle the edges? (I am pretty sure this is true in healthcare, but is it true in other domains as well)

4. Why didn’t RPA giants like UIPath build this? Looking up their approach to MFA (here) isn’t super confidence inspiring. 

5. How do you solve Captchas? Captchas enable a website to know if you’re human, but a) if an agent needs access, is a Captcha necessary? And b) we probably are close to a world where LLMs can accurately do a Captcha - in this world, what’s the point of a Captcha? In addition there are existing providers (eg https://2captcha.com/) with humans in the background that resolve these with SLAs of a few seconds

6. Could a Passkey obviate the need for all this?  Would you need your agent(s) to run on a specific, unique hardware device with it’s own vault? 

7. For the provider of an enterprise webapp (like a payor portal), there’s a meta question of what exactly they think “authentication” means. Does it mean a specific human logged in? Does it mean any authorized entity logged in (regardless of whether that entity is human)? My instinct is that this answer is different depending on the enterprise context - certain enterprise context (like in a lot of financial services back-office) might just not care as long as the work is done. In more adversarial environments like healthcare (where higher provider efficiency translates into more cost of goods sold for payers) I suspect that easier, better authentication for agents and bots is actually NOT desirable at all.

Thanks to Femi Omojola, Owen LaCava, Ali Hussain, Dami Omojola, Daniele Perito, Joshua Levine and Inderpal Singh for reading this in draft form.

[1] referring to both AI agents and bots here because the problem is the same for the 2, and while AI agents are getting lots of airtime today, traditional RPA is already fairly widespread and I think will continue to grow. 

[2] Considering email in particular, there are a few alternatives. I think it’s better to have a dedicated inbox for your bot or AI agent (vs giving it access to a human user’s full inbox) for a few reasons. First, full inbox access doesn’t improve the agent’s performance in any way. Second, you likely want visibility into every single time the agent auths, or accesses credentials, to tie that directly to it performing it’s tasks. Giving a human access to the agent’s inbox means a bad actor can wreak havoc in your enterprise application under the guise of being an agent, and you’d just assume your agent was broken. You’ll also want to log every time a human views the agent’s authentication credentials.

Another alternative would be to create the credentials with an email that’s an enterprise domain mailing/distribution list. This way the password managers don't have to run an inbox that users can see they just need to be allowed to join the mailing list .This will also mean any number of other users & agents can be added and removed (which again means a human can view the credentials without the enterprise really knowing). With that being said, it’s possible that humans misusing agent credentials might be a made-up attack vector that’s not worth optimizing for. Just not sure.

[3] It’s possible that we might have to just abandon SMS 2FA as a construct. Semantically (I think) the objective of SMS 2FA is to tie a login to a human that has been “authenticated” in a few ways (eg when you get a cell phone, you provide a driver’s license, credit card, etc). If you create a phone number for an agent or bot (like if you give a server a sim card) it obviously doenst have it’s own driver’s license (or other id). So is the SMS 2FA authenticating the human who's building/running/employing the bot/agent? Is there a different “signature” or authentication method that more closely ensures a) that the agent can log in this time b) that the entity logging in is the right agent (ie the one that is actually authorized by the enterprise, not the malicious one).

A platform shift is afoot. Both tweets reflect that people in the technology industry (me included) are constantly searching for the next “platform”, and LLMs on some sort of new hardware might be it. I think Esther is right.

Since the smartphone, contenders for the new dominant form factor have been(in no particular order):

• Tablet (kindle, iPad etc)

• Wearables

  • Chest (AI Pin, Limitless, Friend)

  • Wrist (watch, whoop)

• Home Speaker (Echo, Homepod etc)

• (Another) thing you hold in your hand (rabbit etc)

• Glasses (Google Glasses > Spectacles > Meta Ray Bans)

• VR/AR headsets (Oculus, Valve Index, Vision Pro)

I’m sure I’ve missed some. I’ve tried many of the above, and with Meta Ray Bans out in the wild, I’m pretty convinced that glasses (as a form factor) are the closest we’ve come to a “platform” that can rival mobile in terms of breadth. The Meta Ray Bans:

• do things smartphones can’t do 

• do some things much better than smartphones

• do some things as good as smartphones with less cognitive load and

• All these things happen without competing directly with your phone for your attention

Things your phone cant do

Try doing this with your phone. [1]

Do things better than your phone

The Meta Ray Bans are the first wearable in a long time that allow the wearer to be present and in the moment, and critically that provide the illusion to the wearer’s companions that the wearer is present and in the moment. This feels like a huge deal - once you realize it, you can’t unsee your phone as a distraction engine.

We’ve all experienced telling someone something important, intimate or intricate/complex only for their phone to ring at the wrong time, or for them to look at their screen or wrist.  

Glasses are discreet, the wearer’s attention remains focused on their subject or companion, and the notifications manage to be simultaneously more private than a phone ringing with a call or vibrating with a notification while communicating even richer context than either. Wearing this device as a parent is (literally) eye opening. In addition to the discretion & presence it affords you (which already is a lot) it opens up an actually new perspective that is richer/more present for the wearer, AND ALSO impossible for smartphones to replicate. Pretty surprised Apple didn’t ship this first (I know I know Apple doesn’t prize being first to market and still ships market leading product, but still).

The next form factor can’t compete with your hands

Pretty much every hardware successor to phones bill themselves as “not a phone replacement”. This makes sense because phones are insanely versatile and get better every year. Your phone is a compass, calculator, flashlight, still + video camera, credit card, computer, phone (yes an actual phone), communication device, and more. At this point smartphones have been the beneficiary of trillions in R&D investment after they had product market fit. It would be silly to compete head on, and the odds are that they will continue to incrementally improve for decades.

A problem with the pin + companion model is even though they’re marketed as “not a phone replacement” they require you to use your hands. If I had a phone use case that required both hands (eg fast typing for any reason) I couldn’t use a Rabbit (from my test drives the voice input on the AI pin makes it slightly more versatile, but it just doesnt really do anything better than the other device I have in my hand). Inherently I think this meant I was using a much less capable (at least in my perception) device in my hands, just to access LLMs which my apps were kinda better for/mostly as good as. Not saying these devices aren’t good - if they appeared out of thin air in a world without the iPhone they’d probably be just fine/have incremental utility vs. Nokia. But we don’t live in that timeline. Just pointing out - the iPhone is an insane competitor for hand-space, and I think it’s extremely hard for these “hand” alternates to even matter as a result.

To be specific, the Rabbit R1 is functionally a phone substitute because it requires at least one hand to be used, and the phone is already an exceptional hand device. We’ve been trained over the years to use our phones in one hand and eat, drink, or otherwise hold an object in the other. Fundamentally if you need one hand free, you will frequently have to choose between the R1 and your phone.

In contrast, while the AI Pin is not a phone substitute, it actually probably has some advantages over the phone; default voice input, the projector, translation etc. Despite that, a lot of its operating modes require a hand to be occupied, and its user model maps pretty closely to that of a phone (ie you’d use it for a lot of the same functionality).

So, while the experience is different, as long as a user perceives it as competing for headspace, the outcome is not better enough vs a phone. Both devices have other fundamental problems (eg you need to maneuver your whole chest to take a photo, or tap it to activate voice etc) but my point is even if there were ways around these, I think trying to replace the dominant hand device of our time (the smartphone) with a lower utility hand device is a hard slog.

The seed of a very interesting tree

Anyone who wants an LLM on hardware can obviously use chatGPT on a phone, but smartphones are distraction engines.  Unlocking the phone, navigating to chatGPT and then opening the app while dodging notifications just feels like unnecessary overhead. 

I never used the Google Glasses so I don’t have a direct comparison, but my perception is the difference now is LLMs are now good enough to do a lot of things with voice input, which wasn’t true until recently.

Within a couple of weeks of wearing the Meta Ray Bans, I’d already built muscle memory around saying “hey Meta”, using touch, taking photos etc, and most importantly it was easy for those things to be reflexive. I wanted to wear it. When using it, so many things make it obvious that it’s an MVP, but if you think of an MVP as the seed, the tree it could blossom into is probably the most interesting/has the greatest amount of unexpected upside of any wearable I’ve used in recent years. Here’s why. 

Different and better

The R1 & AI Pin are not fundamentally better than the other thing you could hold in your hand. They are slightly faster ways to access LLMs, but they don’t yield any output that is different and better than what you could get with a phone (either technically or from an experience perspective). The Meta Ray Bans are fundamentally better than the other thing you could put on your face (glasses/sunglasses). Given that the current version already fits on something stylish/nondescript that you can wear in public without getting weird looks (which wasnt true for the Google Glasses), the social cost of trying them is relatively low, and the benefits are material in comparison. 

Said slightly differently, the other thing you can hold in your hand is a supercomputer with multiple ways to create & consume all the world’s knowledge. The other thing you can wear on your face is a disconnected piece of plastic.

“Different” in this context means the consumer experiences using the device as different. Eg iOS is a different system from Android, but the consumer experience around interacting with apps and use cases in the real world are basically the same between the two. “Better” in this context means more utility, new utility or “compound utility” (eg collapsing what might have been multiple steps into a single input / output flow). 

Meta Ray Bans are different and better (at enough things) than both smartphones and regular glasses to stand out. 

We all wear glasses 

Big Glass would have you think that >60% of Americans wear prescription glasses. Given how many people dont receive care that they should, and the effects of sunlight on eyes, the actual TAM of people who wear glasses or sunglasses (or should) is probably close to 100%. That’s not actually true for something like the watch (and never has been); watches historically were primarily a fashion choice. Glasses in contrast can be fashionable, but are a utility; lots of wearers can’t see without them. Smartwatches made a good run at turning a watch/wrist device into a utility, but watches in total are still only worn by 35% - 40% of humans. There’s no reason to believe that (as the utility expands and the cost drops) every human might wear glasses loaded with a camera, speakers and an LLM. 

The install base of glasses is already 4 billion, and the potential install base is all humans because every human would derive utility from sunglasses simply by standing in the sun. This isn’t true for anything else.

What could be better

I’ve heard anecdotally that the Meta Ray Bans are internally considered an MVP (as in there’s lots of work left to scale the product), and in using them I get why that’s the case. Some interactions around photo transfer, LLM speed, logistics of literally just getting the device delivered, prompting, and the kinds of answers you get from the LLM just obviously could be better, and I suspect are being worked on and not worth dwelling on. Some of the main hurdles that I think exist are around what it means to have a surveillance device on your face all the time, and the model constraints/limitations.

Surveillance

The prevalence of smartphones make them effectively surveillance devices; there are probably very few situations that exist in public spaces today where you’re not being recorded. The more “interesting” the situation you’re in, the higher the odds you’re being recorded. Even if there are no security cameras, someone probably has you in still or video footage at almost all times publicly. This dynamic will only get worse if everyone’s walking around with a camera on their face. 

I don’t have a good answer for this. Every single additional device that gets connected effectively exacerbates this problem, and I don’t know if there’s a way to reverse it. But if you think about or feel sensitive about privacy, it’s hard not to get the “ick”. The Meta Ray Bans attempt to solve (at least a part of) this with a light informing onlookers about the camera being on. Just doesnt solve for the more elemental dynamic that these things will exist and be prevalent and will inevitably be used in unintended ways.

Model Constraints (or Limitations)

In using the glasses for simple tasks I’ve run into a handful of strange edges. I can’t yet tell whether they are limitations on the model quality or constraints (eg in a system prompt). For example when I asked to count the number of s in this picture:

Claude correctly counted 3. 

In contrast all I got was “there are some trees in the photo”. I can’t tell if this is a Claude vs Llama issue, or the system prompt  or something else.

If anything, the largest hurdle is probably that the cost of these devices to manufacture and the amount of after market service they’ll require (when they break, get wet, or otherwise malfunction)

Surprise, delight, and utility

Beyond providing “presence” and beyond the new perspective (which I think are just head and shoulders better than the alternatives in a really subtle way), there’s a bunch of incremental utility that can work better in the glasses modality, and are DEFINITELY better than the phone. The glasses are not there yet, but you can easily draw a linear path between what exists today, and this future

Many surprises & much delight

There are many things a wearer wouldn’t expect, which are well within reach. They’re just a novel configuration of technology that already exists today. Examples in bullets as a TLDR:

• Camera + Llama means the glasses can give you situational awareness in a way that your phone cannot 

  • Cameras don’t always have to be in the front (way more useful )

• Look and ask 

  • As designed, this is fine. However, the ingredients are there to make this magical.  The magic sauce with look and ask is telling the wearer what is in their field of vision that they do not know is there

  • The magic of an LLM is it has/can have/can synthesize infinitely more context than you can, (theoretically) faster than you can. Not taking advantage of that to surprise and delight is a loss 

• Look and Annotate: take a photo and annotate it; eg

  • Identify all the people/plants/cars/stars in this photo

  • How fast was that car going

  • Scan a document and generate a translated version in {language of choice}

  • How tall is that tree

You can engineer surprise and delight by bringing unknown or difficult to find information back in the response of any open ended question. Over time this can become incredibly personalized; tell the wearer the specific genus of every tree in their field of vision, or the specific distance of every structure, or the specific model of every car. Look and ask becomes a joy, because every time the wearer uses it, they get more specific information than they would have thought to ask, about the environment they inhabit (rather than general information which mostly they can probably deduce from vision and context cues).

Utility

Some of the types of questions I think glasses + model can solve, that I’d like to see:

• Camera driven translation of exactly what you’re looking at

• Audio translation of what you’re listening to (similar to the AI Pin and the new Pixel Babel devices). Unlike the AI pin, this interaction can be invisible to the world. That being said, it’s obviously harder for the device to translate back what you’re saying

• Look at a house and tell me what it cost on zillow/redfin

• What price is this on Amazon 

• What are the dimensions of this window

• Whats the fastest way to get to X

• How far is Y

• How large is this plank

The theme in the utility use cases is compressing multiple steps into a single question. If I wanted to know how large an object was, I could go get a measuring tape and measure it. If I could ask my glasses, then there are all sorts of products in the world that currently exist that the casual or occasional user no longer needs (kind of similar to the accelerometer, gyroscope and more in the phone). 

Eyepods // Apple Vision SE

In many ways Apple is a really obvious company to build a device like this. The fact that Meta nailed the “presence” concept makes it really surprising that the #1 lifestyle/privacy oriented consumer device company hasn’t done this yet. To their credit Apple’s famously rarely first to market and still has such an insane brand halo + technical & design & distribution edge that whenever they get to making glasses, they’ll do just fine. 

But when you know a secret you gain the convictions to do unorthodox things that others without that conviction would find challenging. Meta as an organization knows that secret (that there’s lightning in a bottle in this product), and Apple probably had a chance to deny Meta that secret by sucking the oxygen out of the room, and missed it.

In practice, Apple wont struggle to make connected glasses that are beautiful, loaded with an LLM and deeply tied into the Apple ecosystem. The one area I think Apple will struggle is this;  they’re pretty deep in the “App” paradigm, and all it entails (icons, app specific authentication etc). I have a deep suspicion that there’s a new interaction paradigm to be born here, which will require a non-app abstraction (navigating to a specific app really does break attention in a way that kills the magic of this product).

Beyond this wearable glasses will probably eventually be directly connected to the internet (vs via your phone), include projection in your visual field, etc (since I wrote this Facebook has previewed Orion and Snap has launched Spectacles). These will all unlock material incremental use cases, but I’m focused here on things that are possible to do with the existing hardware and software that exists. 

All this is a long way of saying I’m 99.9% certain that 2 decades from now billions of these will be on peoples heads. Glasses will be larger than the watch, and probably as large as the smartphone. And they’re already here.

Thanks to Kevin Kwok, Robert Andersen and Aaron Frank for reading this in draft form.

[1]  The only words this picture doesn’t say is that you could replicate this perspective with a GoPro strapped to your head, but who wants to wear one of those all day?

For the purposes of this essay, eligibility verification is the process of a) ensuring that a patient’s insurance is valid and current and b) confirming that the services the patient is about to receive are covered by the patient’s benefit. In the fullness of time, I think this can only be fixed by policy (because payors benefit from the current broken state, so have no incentive to fix it as functional eligibility will decimate their margins). In the short to medium term, if you’re a provider group or a care delivery organization optimizing your eligibility process, here’s some detail on the types of issues you might face, and how we approached them.

From what I can tell, there are 2 core problems with eligibility verification today:

1. Fundamentally payors do not want to pay providers. We can say a lot of words about regulating consumption, reducing cost, aligning incentives, narrow networks etc, but this single insight explains 90% of what happens in healthcare revenue cycle (and the rest of this essay.)

Source

2. In order to achieve #1, payors are heavily incentivized for the eligibility verification process (and many other things downstream in revenue cycle) to remain broken.

My point in #1 is not that payors are malicious. It’s that results reflect incentives, and payors’ ultimately are incentivized to be profitable, and a key way to increase profits is to reduce cost-of-goods-sold (COGS). To a payor, providers are (unfortunately) COGS. Without any inside information, I assume a payor is perfectly happy for a member to receive care from a provider, and for that provider to not get paid. The member is simultaneously healthier, the payor got the data, the service was cheap ($0), and the provider didn’t realize the service wasn’t covered until they didn’t get paid, and thus couldn’t direct the patient elsewhere.

I once interviewed someone who said that she ”was tired of working for startups trying to solve problems that only policy can solve”. In that spirit, the actual solution to eligibility verification (and a lot of the downstream problems) is to completely centralize it, or for all payors to be public (government owned). Both paths could solve coordination. But neither is happening soon. Given that, this essay outlines a bunch of the problems in the eligibility process today, a few ways to solve them based on some of the work we’ve done at Carbon and the unique data that's produced, and some insights our results have generated.

The Problems:

Today, eligibility verification (as treated by most providers and as sold by most clearinghouses) is a repackaging of EDI files provided by payors, into a combination of APIs, EDI files, & human readable web portals. For example if you went to check my eligibility for an Urgent Care visit in Waystar you would find:

It’s a human readable view of my covered benefits and cost-share details, organized roughly by the types of care I might receive. An easy way to visualize the start of the problem is to compare what my eligibility information looks like in Waystar (which we use as a clearinghouse) vs. Availity (which is also a clearinghouse, but in this context is used as the portal for Anthem CA).

The entirety of my Urgent Care benefit in Waystar:

And the same thing in Availity:

Remember, this is the same patient, just viewed through different web apps. The difference between the 2 is material; different copays and deductible levels depending on the place of service (and this difference isn’t visible at all in Waystar, and would only be human readable if the person doing registration bothered to log into Availity). 

In our case (for an urgent care/outpatient visit) the stakes are relatively low - average visit cost is in the hundreds not thousands of dollars. But imagine the compounding nature of this opaque behavior as the stakes get higher; either because you’re undergoing inpatient care or you have a chronic disease that requires many encounters.

The Plan

My basic insight is that most providers are actually trying to solve 3 or 4 separate problems when registering a patient and checking their eligibility [2]. The current EDI centered model is insufficient to cover a provider’s needs, the current toolset only partially addresses them, and to date they’ve been ruinously expensive to solve relative to the benefit providers would get. The problems are:

1. Is this patient a member of this plan on this date of service, is the service the provider is about to provide a covered service for the plan, and has the patient exhausted any specific plan limitations for that service (e.g., the plan only covers X number of PT visits in a year). EDI transactions only cover membership [3]

2. Assuming #1 is true, am I (as a provider) contracted with that payer directly, or am I otherwise “in network” (i.e. does the payor consider me to be a provider that they have a list of services and prices they are committed to pay for those services with)

3. Assuming #2 is true, are the services & procedures I’m going to provide to patient covered by their plan? Assuming #2 is false, are the services I’m going to provide covered under that patients out-of-network benefit (or in some other way eg with their employer)

4. Assuming #3 is true, what are the actual contracted rates for those services, what is the patient's financial responsibility, and what can I reasonably expect to get paid by the payor and the patient?

Most eligibility tools today solve #1. Fewer solve #2 (because it requires knowledge of the provider’s contracts). None solve #3 and #4, which is the reason why you walk out of most healthcare visits not knowing how much it costs overall and how much you specifically owe for that visit. Today, a human can manually solve all 4 problems (and you see this happen more often in outpatient specialty care like dermatology) but it’s fairly time consuming and sufficiently imprecise that no one’s really built a service around it. Even large companies like RevSpring and Phreesia don’t do all 4. 

A few things have happened over the last couple of years that can expand the definition of eligibility verification in healthcare to more closely match what patients think it means; that they can walk into a clinic and know they are in network, know the cost of the services to be provided, and know how much they’ll owe. Here’s how:

1. Utilize eligibility from 270/271 files (Everyone does this)

2. Determine if provider is in network with private or public contract data (Carbon doing this with private data)

3. Determine what CPT codes are covered with private or public contract data (Carbon doing this with private data)

4. Calculate patient out of pocket cost and estimate patient responsibility upfront (Carbon doing this, again with private data)

5. Standardize insurance card design and data exchange 

1. Combine EDI & RPA to enrich eligibility & benefit verification

EDI-based eligibility verification already happens today and is quite widespread with a going rate between $0.05c and $0.20c per electronic eligibility call. You can pretty much buy this off the shelf from Waystar, Change Healthcare, Availity, Trizetto, Stedi, Phreesia and many others. In addition, there are a few cases where EDI based eligibility is not sufficient by itself. For instance (using data going back to early 2022):

30% of real-time-eligibility (RTE) attempts fail. 

This number isn’t really all that useful, as it includes input errors as well. However RTE calls fail for all sorts of reasons that are not related to whether or not you have the real patient in front of you who genuinely needs care. RTE failures typically fall into 3 buckets:

• Identification Failures; eg incorrectly identifying the subscriber as the dependent, or vice versa, entering the wrong gender, or a typo in the address, name, date of birth, or member id

• Destination Failures: Sending the RTE to the wrong payor

• Downtime: Clearinghouse or payor failing to respond

We already have the technology to solve these problems, because credit and debit cards exist. Identification failures are solved by the mag stripe or chip; they encode information about the owner of the instrument and the instrument itself. Destination failures are solved by the network; you can pretty much put any payment card into any terminal at this point and be sure that the credentials will be checked at the right place (this isn’t 100% true but it is true enough that most people who have cards don’t worry about it). Downtime will always exist in some way. 

In our workflow, when an RTE call fails, the person entering the patient’s insurance has to re-enter the insurance twice before they can proceed. So 30% of the time, the front desk is re-entering data. This is wasted human effort that we’re all paying for, just for a patient to get seen.

After all the re-entries, that 30% number becomes 10% (basically for 10% of patients who use insurance, we’re unable to get eligibility electronically verified on the date of service, after multiple retries):

This is counting actual finished appointments where the responsible party was insurance, not just verification attempts. Going deeper in, it gets more interesting. On Sundays the failure rate is 20%.

Anecdotally, this appears to be driven by the Blues frequently being down (unresponsive to RTEs) on Sundays (RTE success rates for blues drop by 20% on Sundays, from ~89% to 66%).

Certain carriers are more reliable than others in terms of responding to RTEs:

All this is a long way of saying there’s a meanul amount of cases where RTE just does not work. Today, providers mostly solve this by having their front desk and registration teams log into clearinghouses  or payor portals to get access to patient eligibility data, and interpret what they see, or checking in a couple of days later. However, this degrades your system of record, because the human has to do data entry to make sure what they see in the portal on that day is recorded in the EHR/checkin system. On top of that, clearinghouses and payor portals are often lacking data:

• For some plans, the response is basically empty (as in the provider is told there’s a patient, but there’s no information about the patient’s benefit):

• For certain payors, the response is completely empty, and just says to call them or log into their portal to learn more. So now after logging into your clearinghouse, you ALSO have to log into the payor portal, just to verify the patient’s eligibility. All this time the patient is standing in front of you . . .

• For certain payors the response is fairly rich, but does not include sufficient cost-share information to enable the patient or provider to estimate the patient’s responsibility (we find this happens for about 22% of insurance visits)

All this is a long way of saying, as you design your workflow, some proportion of visits will require manual steps. For these cases, there are a few vendors that enable you to utilize Robotic Process Automation (RPA) to log into payor portals or call on behalf of the provider, retrieve detailed cost share & benefit information, and deploy them into your workflow. These include Opkit, Thoughtful Automation, Luminai, Substrate [4] and many others. This step isn’t critical for every single patient, but without it it’s pretty hard to have a complete view and serve all patients in the same high quality way. This whole process is really lossy; as you can imagine, in lots of cases this step doesn’t happen at all, leading to the provider either spending lots to get paid, or not getting paid at all. 

2. Determine if provider group, or a specific provider, is in network

This problem has a strange shape which is why it’s rarely discussed. Typically, physical world healthcare providers don’t grow that fast, and when they grow, they typically increase density in a single region or grow region by region (this drives the chatter about regional or super-regional monopolies). The result of this is that contracts can be known to a healthcare provider via tribal knowledge (ie the front desk can kind of know whether a particular Cigna plan is in network or not, just because they see a lot of Cigna patients). In addition, many front desks will have a literal physical binder that includes contracts the provider has, what the insurance cards look like, and if there are any plans that are known to be out-of-network. For smaller providers who’ve been around for a long time and are in a single region only, contracts can be decades old since last negotiated, meaning many plans launched since the contract was signed won’t be visible to the practice anywhere, even if they are in network (ie, the provider will only know they are in network because claims sent to that payor are paid rather than denied). 

For a fast growing provider group, or a provider group new to a region, there aren’t really any off-the-shelf solutions for determining explicitly if a patient is in-network. This is a problem because, since the provider group is growing fast they are negotiating a) lots of new contracts with b) lots of new payors in c) lots of new regions and potentially specialties. There are two ways to determine if a provider is contracted with a payor; using the provider’s contracts, or using public payor data released as part of the transparency in coverage regulation. At Carbon, we ingest & structure our contracts with payors to figure out if we’re contracted with a patient’s insurance, and can treat the patient as in-network. 

We do this with a lot of sweat and tribal knowledge decomposing the contracts into a contract administration module (in Carbon’s case we built it into our Billing Hub, but this can also live in the EHR or practice management system) which allows us, whenever a patient’s insurance is entered, to check whether we have a contract with the payor, what services are covered by the payor and what those services cost. Lots of EHRs & RCM systems have a contract administration module that enables clean forecasting (ours does as well). What’s new is using that contract data to estimate patient responsibility. The downside is that this process requires a human in the loop to break contracts down the first time and then to keep contracts up to date as they change (this is one reason I’m excited about the contract automation + claims reconciliation work Recon Health is doing)

The alternative way to determine if a provider is in network is using the transparency in coverage data. Payors are supposed to report this data monthly for every single contract they have in force with every single provider group in the country. It should include a) exactly which providers are contracted, and the negotiated rates for those services. This is initially what I thought we’d do (I even built some tooling to help break down the large files here). I believe in the coming years someone will productize these data to automatically flow into contract modules, and free humans from doing the work (this is an emergent use case of the transparency in coverage data that has yet to take off). The primary caveat (and main reason we haven’t gone this route); payors are required to publish this data or they face significant penalties. However, there’s nothing forcing them to make the contract rates accurate, and as a result I’ve yet to meet a provider or provider group that has been able to reconcile the TIC data to their own internal contracts, and I have multiple proof points that they’re simply inaccurate. Verifying accuracy is ruinously expensive, and my intuition is payors simply don’t care, because they’ll never be held accountable for correcting them (again, this isn't meant as a dig - in a world of limited resources one must prioritize and organizations fairly consistently put compliance actions towards the bottom of their priority list). 

3. Determine rates for covered services in that provider <> payer contract

This is an optional step, dependent on the service being provided. For instance, if a patient is going to an imaging center for a mammogram, it's important to know exactly the contracted rate for the mammogram CPT codes. Knowing this rate will enable the center to calculate how much that patient might owe out of pocket, and bill them for it on the date of service. In contrast, if you’re an urgent care provider, it might be sufficient to only know the office visit code range (as this will likely make up the bulk of the visit reimbursement). 

There’s 2 ways to determine these rates; first using private data, and second using public data.

Determining contract rates using private data

This involves utilizing a contract module to ingest, and create structure from a payor contract. At Carbon Health, this is the approach we’ve taken. It requires a human to retrieve required fields from the contract, and then for the list of CPT codes we care about, enter those codes, the eligible plans, the rates applied and which regions and TINs are applicable, into our system. Recon Health automates some of this process.

Determining contract rates using public data

I previously covered 3 provider use cases for the transparency in coverage data; #4 was checking if a provider is in network, and #6 was extracting negotiated rates for specific services. I still firmly believe someone will build this, and free us all from the tyranny of manually extracting rate data from contracts. Until then, using the contracts you have in house is sufficient.  [5]

4. Calculate patient responsibility up front

When all the patient owes is a copay, this is easy to do. At Carbon, we simply surface the copay amount retrieved from the patient benefit during check-in or utilize the copay amounts on their insurance card. There’s some nuance here as a patient might have multiple different copay amounts indicated depending on the type of service or whether their the covered individual or a dependent:

In our data set (outpatient urgent care and primary care) we’re able to identify a copay benefit for around ~55% of patients. When we encounter multiple different copay amounts, we pick the lower one:

I can imagine a ton of reasons why this rate might differ for different fee-for-service contexts, but the growth of high deductible health plans means that, for non-copay visits, the vast majority of healthcare providers in the US today are unable to tell a patient exactly what they’ll owe at the start of the visit. Because of this, they’re also not able to collect on it. The downstream implication is; very often if a patient has any residual balance after a claim has been adjudicated, the provider won’t have a valid card on file and will have to chase the patient down to get the patient responsibility paid.

The out of pocket calculator

On 2 recent occasions, I’ve noticed specialist providers manually doing this calculation. They’re taking the plan benefit details (co-insurance, deductible, out of pocket max, etc), the service being performed and calculating what they believe the patient will owe, and billing the patient on the date of service. Patients are happy to do this because they know they’ll owe something and they appreciate the transparency. For the provider it solves a few problems: accelerates cash flow, reduces working capital, reduces patient bad debt, and reduces A/R. For the patient they kinda know what they’re in for when they walk out the door, and don’t have the anxiety of getting a random paper bill months later. In the couple of occasions where I’ve seen this, whenever the provider overbilled (for instance when the payor covered more than expected), the provider simply sent the patient a check for the difference. 

At Carbon we built what we call the “Out-Of-Pocket Calculator” to replicate this behavior;  we’ve started estimating patient responsibility on the date of service wherever sufficient benefit details are available (deductible, out of pocket max, co-insurance etc).

1. We combine our contract rates with the accumulated patient benefit data (ie, using the amount of their deductible that is remaining/outstanding, rather than using their total possible deductible) to estimate patient responsibility. For this reason we run RTE checks every single time we’re checking in a patient so we have the most up to date benefit information.

2. During check-in, the front desk will run the RTE to get current benefit data (including their co-insurance, how much of the deductible is remaining, etc), talk through it with the patient, and then walk through the estimate. For certain scenarios (eg if the patient has multiple insurances) we just skip any future steps as it genuinely gets super complicated to determine what the patient responsibility will be after the claim’s been sent to 2 separate insurances.

3. We always assume the most simple thing (an office visit only with no procedures) when figuring out which contracted rate to use. This rate is combined with the patient cost share details to come up with the estimate.  We bill the patient for the estimated amount up front

4. After the claim is adjudicated, the patient responsibility might differ from the estimate for a lot of reasons. 

   1. If the patient's responsibility was less than the initial estimate, the system automatically refunds the patient to the card on file.

   2. If the patient's responsibility exceeds the estimate, the system automatically bills the patient for the balance.

As you can imagine, we try pretty hard not to overbill patients, so we’re extremely conservative in our estimates of what the patient owes. [6] Since shipping this in December 2023, we’ve only had to refund 5% of patients who receive an out of pocket estimate. 

Price transparency is one of the most useful tools for both patients and providers, yet is insanely difficult to execute well. If you’re going this route, ping me as I have ideas. Here are some of the inconsistencies you’ll have to work through when utilizing this data:

• Incomplete cost share information in a single service type (eg deductible and co insurance in urgent care the urgent care service type, but no stop loss )

• Nonsensical cost share details (eg a deductible that’s greater than the out of pocket max, or the remaining deductible in the total deductible field)

• Copay or coinsurance rates in the eligibility response/271 that don’t match the adjudicated amounts in the 835 files

• No cost share details on the insurance card or the 271, but cost share details present in the 835

• Differing cost shares for individual vs. family benefits

Our approach overall has been to use the most conservative cost share details possible to estimate the patient’s responsibility. I think this is why our refund rates are so low. But it would be far easier if the eligibility responses were just accurate + clear. 

Operational Considerations

To do this well, you’ll need to a) measure what is working vs. not, b) get those metrics into the hands of operators and clinical leadership who will c) design mechanisms to hold folks accountable up and down the chain. We’ve somewhat been spoiled because we have control of our technology stack; for most care delivery organizations, different pieces of functionality live across different systems so it falls to the front line staff to stitch things together and maintain context. I think the main items to design are

1. Metrics & Reporting: for every item you want to collect, how often is it being collected, and when it’s not being collected, where, by whom, and why? In our world, we require collection of; consent forms, payment cards, patient responsibilities, insurance cards, driver’s licenses (or other id). When someone skips collecting one of these items, they’re required to select a “Skip Reason”. Skip reasons are also tabulated and all these metrics are rolled up into reports that clinic managers and operational leaders review daily, and use to manage performance and guide coaching conversations

   

2. Scripting: ensuring that the front desk staff has simple, standardized language to talk to patients about their benefit and responsibility. This will differ between contexts (for example outpatient urgent care vs. an ER check in are probably 2 wildly different conversations)

3. Process: making sure these reports are directly embedded in the routine workflow for P&L owners. Insurance capture and patient collection are key to any RCM function, and the P&L owners simply cannot be best in class without managing this process pretty tightly

5. Standardize insurance card design and data exchange 

Eren tweeted a long time ago about putting a QR code on insurance cards:

Source

I think a QR code is a fine solution, BUT it masks a deeper problem which is that the insurance card is the primary authorization instrument for managing healthcare reimbursement in the United States, and every single health insurer in the country designs it differently. Many health insurers have different designs for different plans! For example, here are 8 insurance cards for Aetna plans alone (this is not exhaustive):

There’s no reason the front desk should be an expert in what field to read from the card and manually input where.

A standardized mechanism for exchange (for example, if every single insurance card had a magnetic stripe that could be swiped) would remove so much dead weight loss in the US healthcare industry. Imagine if every merchant had to manually enter your card number into the terminal before changing you? Thats what happens today in healthcare - every provider you go into is scanning + typing in your insurance details. An electronic method of exchanging payor credentials like a magnetic stripe, would reduce typos and registration errors, and ensure claims aren’t rejected for registration or eligibility issues. You could treat dependents like an authorized user of a credit card.

Consider this: you can walk into any merchant in the US, swipe your Visa or MasterCard credit or debit card, and the merchant knows exactly where to check to see if your card is valid , and knows before you walk out that you can pay (including tips!). In contrast, you can walk into a hospital, provide an insurance card, and at multiple steps along the way, the hospital can lose the ability to know where to send your claim. In fact, one core reason many hospitals require a patient’s Social Security Number is to make it possible for them to locate the patient post visit, if for some reason the front desk fat fingers your member ID, or your benefit comes up empty, or it turns out you have a primary payer that you didn't inform the hospital about. 

The lack of a standardized mechanism of exchange is literally costing every US citizen money. There are entire companies built around cleaning up the exchange process. And truly, they should not exist.

People complain about the cost of Visa and MasterCard as middlemen in the financial system. In contrast, the fully loaded cost of an actual transaction in healthcare is 5 to 10 times higher. Here’s a sample of what might be included

1. All-in cost of a Clearinghouse: 0.5% of collections (it’s priced much more granularly, but this is what it comes out to)

2. Interchange for card transactions: ~2% of collections

3. Bank Fees, Lockbox & Claims Reconciliation: 0.5% of collections 

4. Human cost: 3 - 5% of collections

This is why the going rate for using an outsourced billing provider like AthenaHealth or R1 RCM can be anywhere from 5% - 10% of revenue. Compared to this, Visa is cheap (in fairness this isn’t a perfect analogue - a meaningful amount of the cost of RCM solutions is to handle the human led adjudication process based on the codes in the visit, and these often cannot be known prior to the visit). 

Bonus

Coverage Discovery

During the pandemic, when COVID related tests, treatment and vaccines were mandated to be covered, patients had a perception that the government would pay. In practice the way it worked is, your insurance carrier was required to pay, unless you were uninsured. 

How this played out a lot of the time was:

1. Patient comes in, asks for something COVID related (ie a test, vaccine, paxlovid etc)

2. The patient doesn’t provide insurance, and the provider performs the service(s)

3. The provider submits that claim to the HRSA

4. The HRSA rejects the claim with a note that the patient already has valid insurance, and the provider should bill the patient’s insurance directly 

I remember at the time experiencing this and being absolutely surprised + certain that a service for discovering patient’s insurances exists, and we were idiots for not using it (beyond COVID, providers would use these to look up a patient’s insurance if they forgot it, or if a patient has multiple insurances the provider could verify the coordination of benefits so the claim goes to the right place, or for patients who are in an IPA, verifying which procedures could be billed to which payor). In going down the rabbit hole it turns out that there are a handful of services that payors use to do this, but the best, most canonical services that payors use, are not available for providers to use. I’ll leave you to draw your own conclusions.

As a provider group, you can use services like Zoll and TevixMD to fill this gap and do the patient lookup. Currently exploring these - will report back.

HSA + FSA Lookup

Patient cost share (copays, deductible amounts etc) are eligible medical expenses under section 213(d). For a variety of reasons, however, patients rarely pay using HSA/FSA/HRA accounts. Anecdotally from observing patient check ins, this is mostly driven by reflex - most patients at a clinic dont really want to be there, and are nervous/just trying to get their problem solved, and so reflexively reach for their top of wallet card (which logistically just cannot be an HSA/FSA card). 

This could be solved by building a lookup service on top of the main administrators of HSA/FSA cards. Using the lookup, a provider (or their registration service) would 

1. query with patient details to see if the patient has an HSA/FSA balance available, 

2. and if so, retrieve the balance,

3.  surface it to the patient, and ask patient consent to charge the balance.

4. Charge the balance for the patient’s responsibility up front, and true up after the claim has been adjudicated

This is literally better for everyone except maybe FSA providers; patients pay for care using pre-tax funds, providers get paid, it “feels” like found money to everyone involved, and HSA providers get interchange on the transaction. From what I understand FSA providers monetize more heavily on yield on patient balances and so aren’t as stoked about driving spend, but this is purely anecdotal. 

Trying to solve policy problems with technology

When we started exploring this area I mostly believed that there were good ways to solve these problems, and we simply weren’t aware of them. Now we’re in the middle of it and it's pretty clear that doing this well will require a ton of human sweat and effort that few providers can afford to expend. This applies both to finding the right technology to use, and changing staff behavior to drive consistent outcomes. 

As long as payors are incentivized to not pay for services, some version of this problem will exist (and a very similar problem extends to the rest of the RCM lifecycle, into claim rejections, denials, claims posting, and overpayment requests etc). Dealing with thousands of payers creates unavoidable administrative cost and headaches for providers. But payers do not directly bear this cost, and actually benefit from it in some ways, so they have more incentive to extend the status quo than to change it. In addition, no single payer alone can actually fix the problem, because the problem is a result of payer heterogeneity, not the actions of any one payer. 

 The “right” answer systemically is for policy changes to modify the incentive structure (in a weird way, I think the emergence of “payviders” and value based care actually helps here as the same entity is often responsible for both the services and payment). But no individual provider has the ability to change the incentive structure either. 

The fast answer is to build tools to make this work smoothly as an individual provider. That’s what we’re trying to do at Carbon, and we have a lot more work. 

Thanks to Brendan Keeler, Alejandro Novoa, Margaret Goldberg, Sherwood Callaway & Sophie Pinkard for reading this in draft..

[1] At scale, eligibility is continuous, while registration is a one time event. A patient registers at the start of their relationship with a provider, but if their care is carried out over time, their eligibility might change based on changes in their insurance, benefits, the relationship between their plan and the provider, etc. For care over time, eligibility is often re-run prior to each interaction, to ensure the services are covered and no one is surprised. 

[2] This insight, and most of the essay, applies primarily to outpatient care. For inpatient use cases or chronic care I actually don’t have a good model for what the provider is optimizing for (for example, if you show up at a hospital for an ER visit, your out of pocket cost might be thousands of dollars - I just don’t know if hospitals want to have that conversation with a patient, or if patients are ready, or should, etc)

[3] The other massive headache for providers is COB (coordination of benefits). For patients with multiple insurances, it is super hard to know what’s covered under each plan, which plan is primary and should be billed first, and what the ultimate patient responsibility will be. In these cases, actual price transparency is basically impossible. 

[4] For disclosure, I’m an investor in Substrate

[5] Some providers solve this by negotiating case rates: flat rates paid by the payor regardless of what services are done during the visit, or the complexity of the visit. This dramatically simplifies the contract side of the equation, and providers can then focus on getting the correct cost-share/benefit information as inputs into the estimate.

[6] Even getting a clean eligibility response is sometimes enough. Many payers will give members on individual plans a multi-month grace period to pay premiums, but if the member hasn't paid for some period of time, the plan will go back and retroactively terminate the member's eligibility from the first month of non-payment. I.e., the provider can check the patient's eligibility on May 1, receive a response that the patient is eligible, and receive payment from the payer, but then the payer can backdate the member's termination to March 30 and claw back the payment they already made to the provider (and direct the provider to go collect it directly from the patient)