为什么每家AI公司都在不知不觉中建造一座银行：AI时代的金融基础设施危机

Yes, everything is fine. Okay . So, hello everyone. I heard that the match is going on right now . So the fact that you are here means a lot to me . At least I'm winning my " World Cup" now. So this, this is really significant. Thank you for joining me. I flew in from far away , I am the co- founder and CEO of Stigg. I flew here to make a rather unusual announcement at an AI conference: literally every AI company right now happens to be building a bank. And when I say "bank," I'm trying to understand it not as a weird marketing metaphor, but as what's actually happening in the AI ​​ economy right now, and why many of the constructs that we see, use, consume, and pay for actually behave like the structures we know from banking financial systems. So, cool. Thank you for inviting me. Uh, well , let's get started. By the way, I'm the first to speak today. So , the clicker doesn't work. It will be interesting to see how I move forward. Let me tell you a little bit of backstory. When I was writing this report in April, almost every code generation platform simply “broke” under the pressure of this new type of economy and new consumer behavior model. And in just , you know, about five weeks, it all looked like one continuous price crisis after another. I want to prove that these price crises go far beyond simply financial or commercial problems. These are truly infrastructure crises that arise because of how these systems were built from the start. To clarify: in April, Anthropic actually restricted access for Open Clo and other third-party agents to use subscription plans. Then, OpenAI immediately changed the pricing principles for its product, raising the price fivefold overnight, which is quite serious. And then GitHub froze, and later completely canceled trial and free access to its... There's some echo here. To your free plans for Copilot. In fact, all of these companies simultaneously experienced in one month what it means to sell AI at scale and what really happens when you don't have a solid foundation. So let me take one more step forward. So, let's take a closer look at at least one of the use cases, shall we? If you think about Anthropic and remember the case with Open Claude, right? What actually happened was that Anthropic subsidized every consumption of every user who used Open Claude as part of a Claude Pro subscription. So, essentially, customers paid every day, you know , dollars and cents. But on the cost side for Anthropic, it was anywhere from $150 to even $750 in subsidies, which is essentially an economy that can't scale even for a company of the caliber and scale of Anthropic, right? So what seemed like a business problem was actually an infrastructure problem, as Anthropic had no effective way to differentiate between users using their API and users using their subscription programs. And so they had to immediately stop and close access, right? They had to react. Um, okay. So, and this doesn't just apply to Anthropic, guys. We see this, I don't know if you've heard the recent news about how one company, whose name will not be disclosed, burned through half a billion of its cloud AI credits just by letting a few employees use up the entire corporate contract. We had Uber announce that it had effectively burned through its entire annual budget on AI consumption in just a few weeks. And then there was Replit, who gave an example of what can happen if, in one organization, just three users actually spend the entire credit pool for the entire company. So what's really happening is this: it's not just an Anthropic problem. And I think the common thread, if we switch from the examples to what's actually happening, is that the problem in all three of these examples is that the checks of what you're entitled to, what you're allowed to do, whether you're an agent or a user of our AI product, happened after the billing, not before. So essentially, in each of these examples, you were allowed to consume, you were allowed to use the product, you were allowed to spend tokens, and the checks were only made after the bill was issued. So, essentially, costs and their consequences are only reconciled when it's too late, only after the invoice has been sent , and this actually hurts the business, causes price shock, and is a bad practice for using these systems. These systems are now critical, and essentially none of these companies had the financial infrastructure that would allow, like banks, friends, to check before we withdraw funds, before we consume, right? So, I think what we're seeing is really a change in how we design, deliver, and build software. AI doesn't just change the concept of value, it doesn't just change how we interact and who the users are. It also actually changes what exactly is being paid for, and how we actually design systems that can handle the turnaround time, the complexity of use to billing, to audits, and how we can actually design that.

So I think what's interesting, and what you see in front of you, is that on the left we see most teams shipping this architecture today ; and you can see that, in essence, the verification and calculations happen after, after the inference, after the usage has been registered. And usually it's already too late. We see situations like cost spikes, cost overruns, overconsumption —this is an experience that is bad for business, bad for your users, and frankly, in many cases, bad for the provider as well . Because if you haven't allocated enough resources and computing power to allow for that, you also potentially have a margin problem, right? On the right, we're actually saying, or I'm trying to prove to you all, that with AI, with the current infrastructure and the way AI is built and sold, we actually need to implement it synchronously before we update the balance sheets, and reconcile and settle asynchronously after the consequences occur. So, the hot path is actually checked synchronously, and everything that comes after is, in fact, checked later. I think the best example, friends, is if you imagine you're going to an ATM, right? And you withdraw cash . When you withdraw cash, the check to see if you are allowed to withdraw it does not happen after you have received the cash. It happens before you withdraw cash. And it's exactly the same. Our industry actually lacks that level, that financial infrastructure that allows this type of behavior to happen naturally, right? And so, obviously, this sounds like a great idea, right? It seems like you're promoting this infrastructure as if you have some connection to it . Um, but guys, it's not just my fault. In February OpenAI, they have a great team that they call financial engineering. And these guys actually published their vision of the architecture and what they had to build to make it work at OpenAI scale. And what they told me is very similar to the way banks' transaction systems work . Essentially, you have a decision cascade that must take into account at runtime what the client, user, or agent is allowed to do. And he has to take into account a lot of different conditions and policies about what is actually allowed, right? So, are you allowed or do you have access to a certain feature or product? What are the limitations on your plan? Are you on a trial period or in a specific promotional program? You need all of these decisions to be calculated instantly at runtime. And then finally decide: can I give this user access? Can they write off the funds? Can they consume the resource or not? And all of these decisions can't really happen after the bill is issued. They can't, because you need to actually be able to calculate and prioritize this . So I think we have to point out three things here, right? Firstly, this is a single synchronous assessment. This happens during the query. This does not happen after the fact. I think the second thing is that priority is deterministic. So, we know in advance all the different rules that apply to consuming certain things, right? And finally, I think, and here, guys, this is my subjective opinion, you may disagree. I don't think this is billing. I don't think this whole architecture is necessarily just about the idea of billing and payment. This is a financial system that actually makes decisions before any bill, before any payment element. And I think we'll see this increasingly become the standard for other products and other AI systems.

I'll go into a little more detail...sorry, I missed one slide. So, yeah, I'll dig a little deeper into what other features or elements we see in banks that we're used to and take for granted, but in AI they're not as obvious, in software they're not as obvious. Here's just one example, okay? If two separate parties have access to the same bank account , and there is, say, $10 in that account, and they have the right to withdraw that $10. What happens if they both try to withdraw funds at the same time? So , in banking systems there is the concept of retention and settlement. In banks, the problem of simultaneous access has actually been solved, but with AI and agents, this is not the case. You might have, say, 10,000 agents trying to tap into the same pool of funds at the same time, and superficially it seems like they should be able to withdraw money because there is a balance in the account. But what happens when they all withdraw funds from the same pool at the same time? Concurrent access becomes a problem. So how to solve this? This concept in financial systems is known as the classic double- spending problem. She comes from the world of accounting. This is a double entry method. And as I'm sure you're all building and implementing AI solutions today, as your revenue grows and your company scales, the ideas of double-entry bookkeeping , double- billing, and solving concurrent access problems will become important and not be easy to solve later. So think about things like implementing retention and calculation mechanisms, think about idempotence and auditability of these queries, and so on. Another thing that I think is well known in banking systems , but not well established in AI, is the idea that all the different pools have different sources, right? At the bank, you have a debit account, a cash account, a savings account, right? And if you withdraw funds, the bank actually knows how to calculate which account the debit is coming from and what it means. Here, let's say I have a pool of 1,700 credits, but they are not the same, they are different. Each of them comes from a different source. So how do you decide which pool to withdraw funds from? Do you start with the ones that were provided earlier? Do you start with the ones that were on sale? How do you actually calculate what exactly is being charged to users? I think this is a real problem. Most companies today are trying to solve this with single integer databases, and that won't work in the long run. Hmm, cool.

So, to sum it up , I think if you think about how we interact with software, it used to be pretty simple. Before, there were just users and organizations, and there was nothing substantial between them, right? The software consumption hierarchy was quite flat. It was pretty clear who exactly was getting the value. But today, I believe, credit pools are no longer flat. You have many different hierarchies of credit consumption that also require different management, logic, allocation, budgets, and spending limits. What actually happens is that budgets are set from the top, for example, if you sell to corporations, maybe a one-year contract with a prepayment, management or someone else has approved this seven-figure contract, they expect to see those credits spent over the life of the contract. But they want to see more than just being used. They want to know who exactly used them, which team, which users, which agents, to what extent, and they want to have granular control over that. This is literally the foundation of how more and more companies are thinking about selling AI workloads and how they work effectively in production. I'm going to go over this briefly. I think the idea of ​​ what high- cardinality and dimensional graphs are, the ability to analyze data by model types, by users, this whole dimension of consumption—it's probably an interesting topic to discuss. But I really want to go into more detail about these four patterns. So when you build AI and start selling it at scale, there are four patterns that keep recurring, and they're very similar to the idea of banking systems. I think the first one, which we talked about earlier, is the ability to reserve resources before output and make calculations based on usage. This is a pattern we're seeing more and more often, and it affects how you do accounting, how you handle all these different workloads, concurrency, and so on. Second, we see that more and more AI companies are not thrilled about the idea of ​​ sending all this usage data somewhere in the cloud. For reasons of latency, cost, data sovereignty, there are many good reasons why these companies prefer to store event data in their VPC, and I think we'll see more and more companies seriously consider deploying this architecture, this registry and accounting system inside their VPC, instead of transmitting it over the internet. I think, in terms of agent checks, consider how agents are created: the idea of checking balances, where the agent does something and you don't know in advance what exactly they're going to do and how much that task is going to cost in the end . So, if you don't know the value, you need to be able to check those balances while the agent continues to work. And you need to be able to reserve funds for them in advance and then asynchronously reconcile them after execution. Moving on, ultimately, if you have systems like these, you get transparency. It used to be taken for granted that pay-per-use products required transparency, but I think today it goes far beyond mere visibility. This means that the ability for a CFO or CTO to actually see the consumption of AI workloads across different models, functions, and products is no longer just a nice addition. This becomes a basic requirement. It's becoming something that's impossible to do business without, and we'll see more and more companies expect it right away before they start working with you . And by giving examples of how the best cutting-edge AI companies are approaching this, I think you can already see these patterns. So, I think a lot of these companies are already realizing that you're no longer selling software as a commodity, the way we used to think about subscriptions and usage. This is increasingly turning into financial systems, and they require complex ideas that did not exist before the AI ​​ era. Um, and I think it's worth giving one small example that I mentioned earlier, but which may have gone a little unnoticed. Hmm . One of the changes that OpenAI introduced in April was that they didn't actually change the prices. All they did was change the rate at which tokens are spent . So, essentially, you're using the same model, we're paying the same cost per unit, but burning more tokens. So, it was actually a pricing change. How to make such a change? Um, because it's not just a financial change, it's an infrastructure change. You are essentially changing the speed of software consumption. So there are a lot of complexities not just in how we change prices, but also in how the infrastructure allows for more complex ideas about how value is delivered to users. And actually, before we wrap up, our team likes to say—and we've started saying this more often than before— that it feels like the same thing now as it did in the early 2010s, this "Stripe moment," when every company wanted to put products online, and you needed a checkout, it had to be secure, and developers needed everything to work quickly and easily. I think we're at a point now where ideas like building banks... well, if you like wearing a suit and tie, maybe you want to build a bank, but if you do, you should be aware of all the features and elements that need to be there so you don't run into them later when it's much harder to fix. So it feels like the industry is really missing its “ Stripe moment,” where all these structures just exist and are very easy to use. And you know, our team is very inspired by the potential of creating these ready-made systems that will help AI companies continue to release products. If you were interested, be sure to visit our stand. We are in a rather strange place, right at the very beginning, but we are there. I know there's a game going on right now. Come visit. We are holding a product demonstration. Feel free to ask questions, and thank you for coming today. It was wonderful to spend this time with you. And yes, we will be happy to continue discussing the details at our stand.