[#83] The AI Money Movement Layer (Part 2): 5 Blueprints Built on the Same Core Principles

Stripe SPT, Visa Agent Pay, Google AP2: the rails for AI payments are being built. But who verifies the agent? Who catches hallucinated purchases? And where does a standalone player win?

The AI Summit happened in New Delhi last week. And from a fintech perspective, there has been so much buzz around agentic payments, that I just had to go back, relook at my notes, and try to unpack what is happening here. But before we get there, to read some of my past pieces on agentic commerce, check out the below:

1. [#75] The AI Money Movement Layer: MCP, ACP & TAP are launched but are autonomous payments really the future?

2. [#80] Google’s UCP & AP2: Moving agentic commerce from just “plausible” to “scalable”

TLDR: What I’ve tried to do over the last 6 months or so, is really understand:

1. What do we mean when we say “agentic payments?”

2. If agentic payments have to be executed, what has to happen?

3. What or rather, who are agentic payments even solving for?

4. And finally: Is this at a “pilot” stage, or this is at a stage where it can be “scaled?”

I’ll try to answer this through the course of this article.

The big idea, when we think about agentic payments, or even “agentic fintech” is that it’ll sit as a system or rather, a ‘sub-system’ that will be called by AI interfaces

The world has now started thinking about fintech and commerce experiences as a ‘system’ that sits within an AI interface. And when we think about this journey from a person's perspective, we think of something that goes like this:

• User: Hey Claude, buy me this Nike t-shirt at less than INR 200

• Claude: (salutes). Yes, doing right away (through MCP).

  • In a frictionless flow: Claude calls payment APIs, executes the payment, and the payment is done

  • In a flow with 2FA, or Human in the Loop: There is a PIN / Face ID step, but this needs to happen natively in the LLM chat. After that, the payment is done

Now, in both flows, the following needs to happen:

• The LLM (or agent) needs to be able to call merchant catalogues. This happens through MCP, and is solved today

• The LLM (or agent) then needs to be able to call Payment APIs. This can happen in 2 ways today:

  • 1) Each LLM needs to have an individual integration with whatever the merchant has built, which is most probably via the MCP. So, in this case, the merchant’s MCP has to handle everything. or

  • 2) Some sort of browser automation, where the agent does whatever a human would do.

There is no standardized way to call these Payment APIs today (this is where UCP comes in)

Also, anecdotally, having absolutely NO friction, is actually a problem in fintech flows, because this is sometimes perceived by the user as a flow that has inadequate risk checks. I’ll give you an example: With the “SMS less flows” that we are trying to implement, we use something called SMV - or silent mobile verification. All this essentially means is that we are using telecom APIs to verify the customer mobile number, instead of a manual SMS output. In a lot of cases, this happened in less than 1 second, but TSPs had to force-add 2-3 extra seconds, since they found the speed or the “lack of friction” decreased the user trust.

In agentic commerce we are trying to solve both the above (calling shopping and payment APIs within the agent platform), but at the same time, figuring out what the ‘right amount of friction is’

Which brings me to the first question. What is agentic commerce exactly? (Now, in my previous article, I did touch upon this a bit, so feel free to skip this section. But this note is important how I’m thinking about it, so for those of you folks who read the last edition in this theme, it may be a little repetitive. But bear with me, I promise there is a concrete point I’m making here!)

That is simple to answer: It’s any transaction flow, where agents initiate, authenticate, and go through the transaction on a human’s behalf. But, like I’ve done before, to un-complicate it, let’s break this down a little more.

Breakdown #1: Agentic Commerce is: Agentic (Shopping + Payments).

→ Shopping: This has to do more with being able to search agent catalogues, or LLM agents being able to connect with different merchants and so on.

→ Payments is the actual flow of initiating the payment (calling payment APIs), authorizing the payment (someone saying that ‘hey - this payment is authorized to happen, this is not a fraud’), stakeholders accepting that authorization (banks, and networks accepting this authorization), and then the actual money movement happening. A key point here is that MCP is a generic tool calling connector, while UCP is specifically for commerce.

That is where the MCP + a standardized payment protocol (UCP) comes in 👇

Breakdown #2: Agentic commerce doesn’t have to be fully autonomous. It can be partially autonomous too

Agentic commerce can mean everything from 1) fully autonomous, where the agent does everything on the person’s behalf, to 2) somewhat autonomous - where the agent may initiate payments, but there is some human step, which could be either ‘pre-setting up a mandate’ or a final authentication step within the agent initiated flow (like a PIN entry, or biometric authentication).

Breakdown #2 is where there are multiple models evolving: ranging from mandate based, to fully autonomous. Let’s break it down

I have covered some of these in part editions of this newsletter, so I’m not going to go through in detail. But TLDR, there are a few different models, by way of which this is evolving. And this also differs due to the way regulations and stakeholders are set up in the ecosystem.

I have covered the flows in how some models of agentic commerce will work. Again, some pieces you folks may have read before, but I’ve tried to go deeper, and really understand what is happening at each step here, and what the user case looks like

Model 1: The Alipay model (full stack + implicit habits). Specific to the fintech / regulatory set up in the region, and really depends on how much ownership is there across the issuer and acquirer auth stack

Alipay owns each leg of the transaction, and so - implementation here is very easy. A question I had is how, since at the end of the day, Alipay may be the merchant’s PSP, but the acquirer and issuer banks also have to agree to accept the “agents” identity here. Now, the way Alipay works is that:

1. When a user gets onboarded on Alipay, they HAVE to link their bank account. The issuer bank in this case is almost “handing over” the authority to authorize payments to Alipay - Alipay is taking the burden of verifying the customer credentials here

2. Similarly with a merchant, Alipay is taking the liability from the bank on onboarding, and authorizing the payment credit / refunds etc to happen

3. Alipay is also the rails in this case: Alipay maintains a ledger and moves money to banks at the end of the day through its internal settlement process.

4. The agent rules are stored in Alipay’s server

5. Alipay has 80M merchants and 1.3B customers using it. It has enough of a behavioural footprint for this to make sense at scale.

So, Alipay has all 3. Issuer bank authorization to move money. Check ✅ Acquirer bank authorization to accept payments. Check. ✅ And, a massive scale of merchants and customers to be able to execute this at scale (80M merchants, ~1B users - this seems high, but is what is publicly reported. I’d still peg this number at hundreds of million). Check. ✅ That is why Alipay’s AI pay hit ~120M weekly transactions in Feb 2026!

And because it has ownership of each leg, getting these banks to accept an agent’s authority, or do risk checks is easier: Alipay owns this, and gives a “liability guarantee” to the banks in case the agent deducts more that was supposed to happen.

In the Alipay model, because of the data they have on customer behaviour, they are able to make a payment truly agentic, just based on past patterns, and what they call “implicit rules”

What do I mean by “Implicit” rules? Well, they are “common sense” boundaries derived from your historical data. If you buy a $5 coffee every morning at 8:00 AM, the system creates an implicit rule allowing an agent to execute that specific transaction without asking you. Example: If a transaction fits your “Habit Profile” (Let us assume you, basis your behaviour patterns regularly buy coffee of less than $5, the agent is is allowed to autonomously execute. If it’s an outlier (ex: shoes worth $200), which cannot be verified basis behavioural trends, the agent triggers a manual HITL (human in the loop check) which could be PIN, tap or biometric check.

So, in an agentic flow: the user would type Alipay’s consumer app: “Hey, get me a coffee from merchant X.” Alipay takes the request, maps it against the user behaviour, approves it as the issuer bank, approves it as the acquirer bank, and then transfers the money at the end of the day, and records it in its ledger.

Model 2: The Network Rails: Mastercard, Visa, via platform / agent onboarding - similar to Apple Pay

I’ve talked about this in detail in previous articles, so I won’t go into details here. But essentially, the user needs to create an agent, and then Mastercard treats an AI agent like an entity that needs its own passport.

• Know Your Agent (KYA): Think of this like KYC. Before an agent can pay, it must be registered as a Token Requestor. It’s a sort of cryptographic identity that verifies what the agent is and its intended purpose.

• Digital Service Provider ID: When a transaction happens, the “merchant” doesn’t see your card number. They see a Digital ID that says: “Authorized by User X, Executed by ShoppingBot #402.”

• Guardrails are pre-set up: You set structural limits on that specific agent ID itself. For example: “This ID can only spend $100/month and is blocked from ‘Gambling’ or ‘Crypto’ categories.” It is like a corporate credit card with a built-in “Category Block.”

How does agent onboarding happen, and how is the agent actually given authority to make the payment?

1. Anthropic registers Claude as an agent platform with Mastercard/Visa (business deal, KYA review, API keys, like how Uber registered with Visa to charge your card).

1. You aka the user link your card inside Claude’s UI (like adding a card to GPay)

2. Mastercard issues an agentic token scoped to you + Claude + your rules

3. Claude uses that token when paying on your behalf

Maybe a more intituitive way to understand this is how ApplePay works

Here’s the thing. Giving an ‘agent’ authority to pay isn’t a new concept. This already exists! Think of all the times that you’ve added your card or payment methods to a separate device - ApplePay or Google Wallet. Let’s look at this example:

→ Platform registered with network (Visa / MC are the network in this case, and a Claude / Apple could be the platform)

→ User adds method into that platform (could be Uber, Apple, Claude - this is equivalent of adding your card to Uber)

→ At the time of adding this method, the card is tokenized, a reference ID to the token is created and stored with the Agent, which allows the Network to map to the correct card, and ‘keys’ are generated (symmetrical keys, aka same key stored in device and Visa servers in case of Apple Pay, public - private key pair in the case of Agentic Payments, with the private key stored in the agent platform servers, in this case Claude). The key is just a way for identifying that this device / agent is authorized to initiate this transaction and NOT a key to your money

→ In a real time flow, passkeys or biometric credentials unlock the private key access

→ Token (DPAN , agent token) + a request / cryptogram signed with the key is sent to VISA servers. This key confirms to VISA that a registered device or agent is initiating the transanction

→ Visa maps the token to the user saved card (Identity) and authorizes transaction (time stamp, specific context etc) which is in the signed request / cryptogram sent

→ Issuer (Bank + network) approves.

The only difference here is between ApplePay and Agentic payments is that

1️⃣ In the case of Apple, the key is stored in the device (Secure Enclave - separate physical chip in the device, separate from the main processor, supposed to be tamper proof), while in the case of Agentic Payments, it will be stored in the Agent Platform servers.
2️⃣ In the case of Apple, the same key is stored in the device and Visa, while in the case of agentic payments, there is a public private key pair.

Quick thoughts: I am nervous about server side key storage (in the case of Claude etc) - this is a honeypot for attackers. Now, bear in mind, that this private key is not a key to the user’s money. It is a way for the Claude agent to identify itself and say ‘hey, I am allowed to make a request to transfer money. The next step of this is authorizing the payment, which is governed by pre-set up rules by the user, and ultimately VISA takes this decision. However, this is secure info, and ideally should have additional level of security. This is where the industry is moving: to Multi Party Compute (MPC), where this key is further broken and stored in separate locations, in which Silence Laboratories is doing some cool work

A user flow: User does a one time set up on ChatGPT / Claude for method linking. There may be a one time redirection here, since it’s a bad move to enter card details directly into the chat. I’m assuming a one time redirection, and basis that, the tokenized card details are stored with Claude. This is when the private - public key pair is also created. AND, the user has to create some guardrails. Then, at the time of transaction, Claude / ChatGPT will initiate payment using MCP / UCP protocols. Visa will check the agent identity (private - public key), check the method token (map token to real card details), check guardrails (request is within lets say $200). If all is well, it will approve the transaction.

Model #3: The mandate style: Google (AP2 Mandates, using existing mandate blocks, Razorpay + UPI reserve pay)

I’ve written about this in a lot of detail in the past, so I won’t go into it in too much of detail. You can read about it here. High level, this is a way to conduct autonomous payments by pre-setting authorization.

In the case of Razorpay x Claude x Open AI and UPI Reserve Pay, the payment instruction has been set up one time at the merchant

The user flow is as follows: I go to the merchant, and set up a UPI Reserve Pay instruction, which is essentially a payment block on the merchant, of upto INR 1L. This is a limit, against which a user can make multiple transactions on the merchant. It’s different from UPI Autopay, because Autopay is a standing instruction to transfer funds. It isn’t blocking funds in the user account for that transactions on that merchant. UPI Reserve Pay goes and blocks funds in the users account of upto some amount, and debits can keep happening against it. Example: If the limit set up on the merchant is INR 15k, the user can do fifteen, INR 1000 transactions on it and so on.

• Pros: Fully autonomous, and secure, since the user has pre-authorized this

• Cons: It needs to be set up at a merchant level. This may only really work for low value, high frequency transactions.

Google’s AP2: a trust layer that stores mandates

1. The user sets up a mandate on their user app or wallet. This user app or wallet has to be onboarded on AP2

2. The wallet, the user app, and the bank all have a copy of this mandate stored with them (since all have to be onboarded on AP2)

3. The Agent (ChatGPT / Claude) also has to be onboarded on AP2, so that they can sign requests (same logic as above, this verifies that this is a genuine agent initiating the transaction). So for the invisible flow to work

   1. The user must pre-set up the rules on their app / wallet

   2. The Agent (Claude): Must have an AP2 “Identity” (to sign requests).

   3. The Merchant: Must use UCP (Universal Commerce Protocol) to sign the shopping cart.

   4. The PSP (Stripe/Adyen): Must be able to “read” AP2 mandates and pass them to the bank.

   5. The Issuer (Bank): Must be able to verify the cryptographic signatures on the mandate.

The good thing about AP2 is that it is an open standard, so anyone can onboard, and then use it across entities. It isn’t like Stripe’s ACP, which can only be used on Stripe. The problem here though is the same: EVERYONE in this chain has to be onboarded on AP2. If even one isn’t, then it fails. And of course, the same mandate issue: For the user to go and set up mandates per merchant or category can get tedious.

But this is tough to predict, and we’ll see how user behaviour evolves.

Model #4: Tight, context bound token: Stripe (may be the way other payment gateway layers also go)

Stripe uses short lived context to ensure the AI doesn’t go rogue. This isn’t like an “agent” that is onboarded on VISA / MC previously, or some sort of mandate that is set up, like in the case of UPI Reserve Pay, or AP2

• Token Policy: When you chat with an AI (like ChatGPT), Stripe generates a Shared Payment Token (SPT). This token is “created” with a set of rules attached to it, and is created directly by the LLM Agent, by calling Stripe APIs (

• Dynamic Scoping: The policy is generated from the user LLM chat intent. If you say “Buy this $40 book,” the SPT is generated with a policy that literally says: MAX_AMOUNT: 40.00, MERCHANT_ID: 12345, EXPIRES_IN: 15m. This SPT is then passed by the LLM chat to the merchant, which creates a payment intent on Stripe.

• The Integrity Check: Stripe does the validation: it checks if the payment intent amount is < SPT. It checks if the token is expired or not, and if the merchant is as per the SPT. If the agent tries to use that same token to buy a different book or at a different store, the Stripe gateway rejects it instantly because the metadata on the token doesn’t match the request.

• These rules are stored at the Stripe layer, so essentially Stripe is taking that responsibility of making sure that no MORE than the authorized payment basis the token is debited from the client account

So, in a regular flow: Mode A: User in the loop (today)

• User says: Hey Claude / ChatGPT. Book me a flight from A to B under INR 15,000

• Claude / ChatGPT: “I found this flight for INR 12,000. Pay now?”

• User: “Yup, go ahead”

• Claude then opens Stripe Checkout link in browser. User: Sees INR 12,000 on Stripe page → enters OTP / biometric. There also be a flow where this opens in the Claude / ChatGPT chat window using an ‘Apps SDK’ type flow (like what Cashfree has done), so the OTP / biometric step still happens within the LLM chat

• Stripe: Charges card → confirms to merchant → confirms to Claude

So, in the new agentic flow: Mode B: Using Stripe APIs to create a Shared Payment Token, and validate without additional OTP / biometric step needed

• User says: Hey Claude / ChatGPT. Book me a flight from A to B under INR 15,000

• Claude / ChatGPT: “I found this flight for INR 12,000. User approves / clicks ‘buy’ in the chat interface OR could also be autonomous if Stripe tomorrow allows rules to be set up. In fact, with the rumoured Paypal acquisition by Stripe, this could give Stripe a user interface on which the user could set up guardrails very easily, and this could move them more to the Alipay model of things.

• Claude / ChatGPT: Issues the SPT, locks to the specific merchant, and gives a time out in 15 minutes

• Merchant gets SPT, creates a “payment intent” in the backend with Stripe

• Stripe checks the amount in the payment intent with the SPT. If the amount < = SPT amount, then the payment goes through

• Stripe: Charges card (customer details tokenized and saved in Stripe vault - product is called Stripe Link), so this can be used across any merchant on Stripe → confirms to merchant → confirms to Claude

Key point to note: Stripe’s moat: a seamless flow to transact, without pre-set up mandates or native biometric flows, or redirection.

Model #5: Autonomous only till authentication: native flow inside the LLM (Cashfree + Biometric)

This is pretty straightforward, and this is the human in the loop method. MCP is still being used to call merchant APIs, and the Agent is still calling Payment APIs - either directly (like in the the case of Stripe ACP), via UCP (Google implementation), or through merchant MCP (merchant MCP also handles payment). But in cases where there is 2FA, or an additional step of auth is required, that step happens natively within the LLM chat, not redirection.

Cashfree demoed this at the AI summit in Feb 2026, with OpenAI with Swiggy and Mastercard, which allows for native biometric based passkey authentication within the LLM chat. This is exactly like a payment flow today, except the interface is the LLM chat and not the merchant or the payment app.

So, there are different models here, all trying to solve for ‘in LLM chat’ payments, but through different implementations

• MCP → this is mainstream at this point. However, what I’m still on the fence about is if MCP will also be used to handle payments, or will there also be a UCP type implementation that stakeholders will do?

• UCP → Still early days, but this will essentially be another protocol that stakeholders will have to be onboarded on. Merchants will have to build the UCP schema within the MCP (MCP is like the pipes, and UCP is the language: remember, it helps standardize payment states). The thing is, it is still very new, so it’ll take time to figure out what protocol is here to stay: the big players that will win are the one that have distribution for sure, but will it happen via the MCP (with UCP schema), or via MCP calling Payment APIs separately is something we will have to see play out.

But, like with flows with lesser friction: this is probably going to initially work for low value, high frequency transactions.

UPI had 21B transactions in January 2026. And the total value processed in these transactions was INR 28.3L Cr. This is an average transaction size of INR 1305, or $14. This is after UPI processes ~70%+ of online digital transactions, but has some friction (PIN).

It really depends on user comfort. But a lot of the mandate based / guardrail based models of agentic payments will work for habitual, and daily lifestyle transactions. That is because I really don’t see users taking the trouble to do the one time set up, UNLESS they are transacting frequently enough

But despite the different models, the foundations of all AI agents in commerce remains the same:

But some things remain the same. The foundation is the following:

1. The Agent needs to be onboarded at a platform level on the payment providers: be it MC / VISA / Stripe or whoever. So a ChatGPT / Anthropic needs to be onboarded here, and a specific identity given to them so that stakeholders can check this is a verified agent.

2. The Payment method linking needs to happen on the Agent, via a one time handshake. At no point should the saved card details be exposed to the agent

3. Authorization needs to controlled very tightly: either via pre-set up mandates, or contextual tokens in the case of Stripe

4. There has to be a way for the PSP to validate the amount passed by the LLM: this happens through card mandates that the merchant signs, and the PSPs check against - they don’t just blindly trust whatever the LLM agent sends

5. Liability: Who takes the hit if agents go rogue?

Even in this new ‘agentic flow’ payment orchestration will still be required to help the agent route the transaction to the best PSP and method, and will sit on the UCP layer

To understand where they will fit, let’s first look at the e2e flow. Now, putting together everything we’ve been talking about in the above sections. Essentially, the LLM agent calls the merchant MCP, which then calls the UCP to call payment APIs of PSPs. And then subsequent methods are called, depending on what is set up / available, and finally the auth layer comes in, which can be user driven, or using pre-set up mandates.

Now: An open question right now (and this is probably some time away) is that how will the agent route to different Payment Providers or methods? It only has visibility on the methods that have been linked to it. Well, in its current form, the agent will go to whatever PSP is integrated on the merchant for agentic payments. Which isn’t that many right now, since it is still scaling. In the future, it’ll only be able to route basis the methods it has linked to it, and the previous success rates that different PSPs have. This could play out in 2 ways:

• Users link all their methods on Claude. Very unlikely.

• (Drumroll please): An orchestrator layer that has visibility on stored user credentials, and authentication mechanisms like Juspay. It sits on the UCP layer providing the agent intelligence on which PSP to route to basis which the agent takes a decision or show options to the user for a human in the loop flow

What about standalone agentic payment players? What is the scope for them?

I think anyone innovating on the rails is in for a tough time. Everyone big LLM and payment player is going after this, and is probably in a better space to win this, just because of the distribution and ownership of the full stack they already have. Look at the example of Alipay: 120M weekly transactions, and a big reason for this is because they have 1.3B users, and 80M merchants already onboarded. This gives them a lot of leverage with stakeholders, and they already own a big chunk of the stack. So:

• Building a platform JUST for payment agents? Tough: Most of the distribution is there with existing LLMs. Maybe for niche use cases: like BNPL agents? Tough to predict 🟡

• Agent orchestration: The key assumption here is that there will be multiple agents for commerce and payments. First principles: I feel this really depends on the user choice of LLM, and they will stick to that. But this is tough to predict, it is also possible that tomorrow a platform pitching “personalized agents for commerce” wins. 🔴

• Payment Orchestration: Existing orchestration players will win, the nuts and bolts are the same. Every existing PA has orchestration across PSPs and methods 🔴

• Standardizing Payment APIs: Google’s UCP is doing it across PSPs. However, it is tough to cover the long tail, and I feel that it is possible to build a standardization layer here for regional or niche payments. Example: BNPL as a method, or local card payments, or wallets may not be something all PSPs cover. However, the market size is something that may not be big enough 🟡

• Trust and identity of agents: Something I have been harping about this this piece, is that the agent identity needs to created, but at the same time, treated different as compared to a human, since there will be different risk rules as well. Right now, each agent needs to onboard on each platform separately, and have an identity / ID created. Example: An Anthropic needs to onboard on Stripe, Mastercard, VISA and so on. Some sort of cross platform agent identity standard, or scores for agent trust doesn’t exist today 🟢

• Agent specific fraud: Entirely new category. Existing tools don’t detect agent hallucination/prompt injection 🟢

• Data encryption in these new payment flows: Agentic payment flows create new payment flows that don’t exist today. (the whole MCP → UCP → in LLM chat → pushing context and so on). There are multiple unsolved problems: context leakage, cross-agent data sharing, encrypted enclaves, payment DLP

Here’s my mental model on this:

It is tough for newcomers to win on anything on existing rails (orchestration, processing, standardization). Incumbents have distribution, data, trust, and will add “agentic” as a feature. Like orchestration for example. But where standalone players do have a chance to win is on net new categories that don’t exist today. The reason for this is that these are not “adding agentic to existing payments.” These are “new problems created BY agentic payments”

But what I have gathered is: I do think we have a way to go to build the support layers for this

In-LLM payments are inevitable. The pipes are being laid: UCP for commerce, AP2 for authorization, Stripe SPT for checkout, Visa/MC agentic tokens for card rails. Every major player is building their piece. The framework exists on paper, but when it’ll actually fit together is something that will take time.

But fully autonomous agent payments, is something I’m still not bullish on. The history of payments teaches us one thing: friction is a feature, not a bug. Every payment innovation that scaled , from UPI, Apple Pay, contactless cards, they all keptthe human in the loop at the critical moment.

Removing that entirely, and letting an agent spend your money requires a level of trust in AI that doesn’t exist today and may not exist for years. Not because the technology can’t do it, but because a lot of things are not ready yet:

1. Fraud frameworks aren’t ready. Current fraud detection is built for human behavior patterns. Agent hallucinations, prompt injection attacks, are new threats with unproven defences

2. Data encryption is an afterthought. Payment data flows through LLM context windows, MCP calls, and agent communication. Is this actually safe?

3. Business models are unclear. Who captures value in this flow? If UCP is open, AP2 is open, and card rails are commoditized, where does margin live? The Stripe model (own the processor) works. The Visa model (own the network) works. But will the cost of agents themselves be worth the value they bring? Is there a direct revenue / GMV increase that can be correlated to agentic payments?

What will likely happen:

The near-term winner is assisted commerce: the agent finds the deal, builds the cart, recommends the best price, and presents a one tap checkout. The human confirms. This is already achievable (see Cashfree), and doesn’t require solving the trust problem. Fully autonomous payments will emerge in narrow, high-trust, bounded contexts first recurring subscriptions, and pre-approved categories

The companies that win won’t be the ones building the most autonomous agent. They’ll be the ones that make the human in the loop moment so seamless that it feels autonomous: a biometric tap, native flows, passkeys, while keeping every guardrail intact underneath.