DEV Community: Tom Wang

AP2 vs ACP vs x402: Who Holds the Credential?

Tom Wang — Mon, 14 Sep 2026 07:16:33 +0000

In ACP, the agent platform vaults the card and hands the merchant a token capped at the checkout total. In AP2, a Credential Provider keeps the card and the user signs an SD-JWT that says what the agent may do with it. In x402 there is no card and nothing to vault: the payer's wallet signs a one-off USDC transfer and a facilitator puts it on-chain.

Those are three different answers to the question of who holds the money. Most pages ranking for "AP2 vs ACP vs x402" skip that and describe layers. Several, one earlier piece of mine among them, still explain AP2 with Intent and Cart Mandates, which the v0.2 spec replaced in April 2026.

What Is the Difference Between AP2, ACP and x402?

They standardise different things. ACP is a merchant checkout API. AP2 is a format for signed evidence that a user authorised an agent. x402 is an HTTP handshake for paying on a stablecoin rail. You can use all three in one flow, and the specs increasingly expect you to.

	AP2	ACP	x402
Governed by	FIDO Alliance (donated by Google, 28 Apr 2026)	OpenAI and Stripe	x402 Foundation, Linux Foundation (operational 14 Jul 2026)
Current version	v0.2	`2026-04-17`	Spec v2
What it defines	Mandates and receipts	Checkout sessions, delegated payment, product feeds	402 challenge, payment payload, facilitator API
Who holds the credential	Credential Provider	Agent platform's PSP or vault	Payer's own wallet
Proof of authorisation	User-signed SD-JWT mandate	Single-use token with an `allowance`	EIP-3009 signature per payment
Money moves on	Any rail the processor supports	The merchant's existing card processor	On-chain, e.g. USDC on Base (`eip155:8453`)
Dispute path	Evidence only, resolution out of scope	Normal chargeback via merchant of record	None in the spec
Transport	Extension to A2A, MCP and UCP	REST, plus MCP from `2026-04-17`	HTTP headers, A2A, MCP

The x402 Foundation launched with 40 members, including Adyen, American Express, Google, Mastercard, Shopify, Stripe and Visa. That membership overlaps almost entirely with AP2's and ACP's backers, which tells you nobody expects one protocol to win outright.

How Does ACP Checkout Work in 2026?

The merchant implements five endpoints:

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

Variable Recurring Payments API: The Hard Parts

Tom Wang — Sun, 06 Sep 2026 07:22:45 +0000

Several of the guides that currently rank for "variable recurring payments API" list MaximumCumulativeAmount and MaximumCumulativeNumberOfPayments as VRP control parameters. Neither field exists. I checked the published OpenAPI definitions at v3.1.10, v3.1.11 and v4.0.1, and there are zero occurrences in any of them.

That is roughly the state of VRP documentation outside the specification itself: thorough on sweeping versus non-sweeping, silent on everything that actually costs you a sprint.

What Is the Variable Recurring Payments API and Who Has to Offer It?

A VRP is one long-lived consent that authorises many payments underneath it, each validated against limits the customer set when they authenticated. It is not a payment message repeated on a timer. It is a mandate held at the bank, with the bank enforcing the caps.

There are two flavours, and the split is regulatory rather than technical. The CMA mandated that the CMA9 offer open access to the VRP API for sweeping, which means moving money between accounts belonging to the same person. Open Banking Limited states the other half just as plainly: non-sweeping VRPs were not mandated by the CMA, so the CMA9 are not obliged to provide them. Six of the nine (HSBC, Santander, NatWest, Nationwide, Lloyds and Barclays) had sweeping live by the end of 2022. Sweeping is now a real rail, running 7.73 million payments in June 2026, up 6.7% on the month.

Commercial VRP is the one everybody writes about, and it arrived through a scheme rather than a mandate. The UK Payments Initiative went live on 2 June 2026, one quarter later than the Q1 2026 the FCA and PSR had signalled in December 2025.

The current standard is v4.0.1, released 1 April 2026, base path /open-banking/v4.0/pisp. The CMA9 were required to be on v4.0 by the end of March 2025, and running OBL 4.0 in production is a prerequisite for UKPI participation. If you are still building against 3.1.x, you are building against a migration target.

What Endpoints Does the VRP API v4.0.1 Expose?

Six paths, eight operations, and one of them is a trap.

Method	Path	Purpose
`POST`	`/domestic-vrp-consents`	Create the mandate
`GET`	`/domestic-vrp-consents/{ConsentId}`	Read mandate + status
`DELETE`	`/domestic-vrp-consents/{ConsentId}`	Revoke
`PUT`	`/domestic-vrp-consents/{ConsentId}`	Version migration only
`POST`	`/domestic-vrp-consents/{ConsentId}/funds-confirmation`	Balance check
`POST`	`/domestic-vrps`	Execute a payment
`GET`	`/domestic-vrps/{DomesticVRPId}`	Payment status
`GET`	`/domestic-vrps/{DomesticVRPId}/payment-details`	Detailed status history

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

Rust's $350k Bet and an 86-Minute Attack

Tom Wang — Fri, 28 Aug 2026 09:23:47 +0000

At 07:15 UTC on 20 August, someone published arrayref 0.3.10 to crates.io. It was live for 86 minutes, picked up about 2,285 downloads, and every single one of them executed attacker-controlled code on the machine doing the build. That code ran before a single line of the project itself had compiled.

arrayref has 250,376,732 lifetime downloads. Fewer than 10% of its normal daily installs touched the poisoned version. The reason is unglamorous and worth sitting with: most teams had a Cargo.lock pinning 0.3.9, so Cargo never went looking for anything newer.

Six days later the Rust Project announced its first Maintainers in Residence, directing $350,000 at six people for at least twelve months. Both stories landed in the same week, both are about who keeps Rust standing up, and the gap between them is the thing I want to talk about. As a fintech developer who has shipped Rust into payment systems, my read is that the funding is genuinely good and does almost nothing about the attack that preceded it.

What Actually Ran on Those Build Machines

The mechanics are worth spelling out, because most coverage stopped at "malicious crate."

The compromised arrayref 0.3.10 did not contain malware. It added one line to its manifest:

[dependencies.proc-macro1]
version = "1.0.107"

proc-macro1 is a typosquat of proc-macro2, one of the most-depended-on crates in the ecosystem. The real payload lived in proc-macro1-1.0.107/build.rs. Because Cargo compiles and runs build scripts for every crate in the graph, it never mattered that arrayref didn't call a single function from it. Resolving the dependency was enough to detonate.

The build script reassembled its command-and-control address from base64 fragments (23.254.165.112, port 9089 for the payload, 443 for the beacon), then installed a certificate verifier that returned success for everything it was shown. That let it pull a binary over TLS from a raw IP with a self-signed certificate without a warning. It selected a platform-specific payload (rust-crate_0.1.0 for Linux x86_64 through rust-crate_0.4.0 for macOS ARM64), wrote it to /tmp/rust-setup, chmoded it, and spawned it detached with all streams sent to null.

The Windows path is the part that tells you these people had done this before. Cargo puts child processes in a job object, so they die when the build finishes. The attacker wrote a PowerShell script to %TEMP%\rust-setup.ps1 and launched it through a VBScript wrapper under wscript.exe with CREATE_NO_WINDOW. The comment in the source said it plainly: this escapes Cargo's job object. The process outlives the build.

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

Mastercard Settles Cards on Solana, 24/7

Tom Wang — Mon, 08 Jun 2026 15:37:04 +0000

On 3 June 2026, Mastercard quietly rewired one of the oldest assumptions in payments. The company announced it will settle card transactions on-chain in regulated stablecoins — intraday, at weekends, on bank holidays, around the clock — with Solana as the lead settlement rail. For most consumers this changes nothing visible. For anyone who builds payment infrastructure, it is one of the most consequential back-office shifts of the year. As a fintech developer and payment developer who spends his days inside settlement and reconciliation systems, I think this is the moment on-chain settlement stopped being a pilot and started becoming plumbing.

What Mastercard Actually Changed

Card networks have always run on a split-brain model. Authorisation happens in milliseconds — your card is approved at the terminal almost instantly. Settlement, the part where money actually moves between the acquiring bank and the issuing bank, happens in batches during banking hours, typically T+1 or T+2. That mismatch between instant authorisation and delayed, business-hours settlement is a relic of correspondent banking, and it is exactly what creates float, reconciliation headaches, and weekend liquidity gaps.

Mastercard's announcement attacks that gap directly. Raj Dhamodharan, the company's EVP of blockchain and digital assets, framed it bluntly: "The next phase of stablecoin adoption is about real-world utility, especially in settlement." The network will let participants settle in a basket of regulated stablecoins — Circle's USDC, Paxos-issued PYUSD, USDG and USDP, Ripple's RLUSD, and SoFi's SoFiUSD — across eight blockchains including Arbitrum, Base, Ethereum, Polygon, Solana, XRPL, Canton and Tempo. Solana is the launch rail for the deepest integration.

Early adopters named for the rollout include Cross River, Lead Bank, CBW Bank, ARQ (formerly DolarApp) and Nuvei, starting in the US and Latin America and expanding through 2026. This is an early-phase rollout, not a flip-the-switch GA event — USDC settlement is already live in select markets, and the rest is staged. But the direction of travel is unambiguous: a network spanning billions of cards is moving its settlement layer onto rails that never close.

Why Solana, and Why Developers Should Care

The most interesting detail for engineers is how this is wired. Mastercard's settlement does not run through a bespoke, hand-rolled chain integration. It flows through the Solana Developer Platform (SDP), the API-driven institutional toolbox the Solana Foundation launched on 24 March 2026 with Mastercard, Worldpay and Western Union among the anchor partners.

SDP matters because it abstracts the chain away behind three modules: tokenised real-world asset issuance, fiat-plus-stablecoin payments, and a forthcoming trading and on-chain FX module. Under the hood it unifies more than twenty infrastructure providers — node access via Alchemy and QuickNode, custody and wallets through Fireblocks and Coinbase, and compliance screening from Chainalysis and Elliptic. Worldpay already uses it for merchant settlement; Western Union for cross-border. In other words, a payment engineer integrating against this stack is not writing raw Solana programs from scratch — they are calling an API surface that handles issuance, custody, and compliance hooks for them.

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

UK Open Banking Launches Its Card Challenger

Tom Wang — Sun, 07 Jun 2026 10:33:38 +0000

For eight years, UK open banking has been a brilliant set of rails without a timetable. The plumbing worked — millions of account-to-account payments cleared every month — but there was no shared commercial framework to make recurring, card-free payments a mainstream default. On 2 June 2026, at Money20/20 Europe, that changed. The UK Payments Initiative (UKPI) went live with a finalised rulebook, a commercial model and operational standards for flexible, automated, recurring account-to-account payments. As a fintech developer and payment developer who has spent years wiring up Open Banking APIs, I think this is the most consequential structural upgrade to UK payments since Faster Payments launched.

This is not another pilot. UKPI Ltd is backed by an unusually broad coalition of founding shareholders — Barclays, HSBC, Lloyds Banking Group, NatWest, Nationwide, Santander, Monzo, Revolut and Starling on the bank side, with Acquired, GoCardless, Plaid, TrueLayer and Yapily among the fintech founding members. When the high-street banks and the open banking fintechs sit at the same table and agree a rulebook, the thing that has been missing for years finally arrives: certainty.

What the UKPI scheme actually standardises

The headline capability is commercial variable recurring payments (cVRP) — recurring account-to-account payments where the consumer, not the merchant, sets the rules. Under the scheme a payer can define how long a permission lasts, the maximum that can be taken, and exactly who receives the money, all without sharing card details or setting up a traditional direct debit. The permission lives in the bank, is visible in the banking app, and can be revoked in one tap.

For a payment developer, the value of UKPI is less the technology — VRP has existed as an API pattern for a while — and more the scheme layer sitting on top of it:

A shared rulebook that defines liability, dispute handling and refund obligations across every participant, so you build to one specification rather than negotiating bilaterally with each bank.
A commercial model that finally answers "who pays whom" — the question that quietly killed countless open banking business cases.
Operational standards for availability, performance and consumer protection, moving cVRP out of bespoke bank-by-bank integrations and toward predictable, scheme-grade reliability.

The FCA, which published a supporting statement the same day, called it "a major step forward for open banking and commercial variable recurring payments" and said it expects the launch to act "as a catalyst for other initiatives to emerge." Critically, the regulator confirmed it will consult on a long-term regulatory framework by the end of 2026 and supports establishing an independent standards-setting body. That sequencing — industry ships the rulebook, regulator codifies it afterwards — is how durable payment infrastructure usually gets built.

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

AllUnity's SEKAU: A MiCA Stablecoin for Agents

Tom Wang — Fri, 05 Jun 2026 11:35:37 +0000

Two weeks ago I argued that the 98.6% USDC concentration running through agentic payments was the most under-discussed structural risk in the space. Ten days ago Tether and Georgia shipped the first sovereign-paired non-USD stablecoin as one possible answer. This month the European response is landing too, and it is shaped very differently.

Frankfurt-based AllUnity, a regulated European stablecoin issuer and licensed e-money institute backed by DWS, Flow Traders, and Galaxy, has confirmed the imminent launch of SEKAU — a Swedish krona stablecoin issued under the EU's Markets in Crypto-Assets (MiCA) framework — and paired it with Agentic Payments, a settlement product built on Coinbase's x402 standard that drops AI-agent transactions directly into European local bank accounts. Both are targeted for go-live in June 2026, subject to final regulatory approvals.

SEKAU joins AllUnity's existing EURAU (euro) and CHFAU (Swiss franc) and becomes the issuer's third European currency denomination. In a market where dollar-backed tokens still hold roughly 99% of global stablecoin supply, this is now one of the larger families of regulated, MiCA-grade non-dollar alternatives in circulation.

Why MiCA Changes the Shape of the Story

The headline is the asset; the substance is the regulatory wrapper. MiCA is the first comprehensive, supranational regulatory framework for crypto assets in a major economic bloc, and it imposes a specific, prescriptive set of obligations on stablecoin issuers — sometimes called e-money tokens (EMTs) under the regime:

1:1 reserve backing in highly liquid assets, segregated from issuer funds.
Redemption rights at par for holders.
Authorisation as an e-money institution (or credit institution) in an EU member state, with passporting rights across the rest of the bloc.
Ongoing prudential and conduct supervision, including reserve audits and disclosures.

This matters for engineers because it changes what "support a non-USD stablecoin" actually costs you in production. SEKAU is not a community-issued asset on a chain you have never heard of. It is a regulated EMT, issued by a licensed e-money institute, with defined reserve composition, defined redemption SLAs, and named supervisory authorities. From a counterparty-risk and settlement-engineering standpoint, that profile is dramatically closer to "accept SEPA Instant" than to "accept a random ERC-20."

If you have been routing through stablecoins in cross-border flows and worrying about which jurisdiction's rules apply on which leg, MiCA-grade EMTs are the cleanest stablecoin asset class to integrate today. They were designed to slot into the same legal and operational vocabulary as bank money.

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

GitHub Copilot Just Made Every Dev a Metered API

Tom Wang — Wed, 03 Jun 2026 08:33:11 +0000

On 1 June 2026, GitHub switched Copilot to token-based usage billing. The plan prices look the same on paper — Copilot Pro is still $10/month, Pro+ is still $39/month, Business $19/user, Enterprise $39/user — but the meter underneath has changed. Once you exhaust the included monthly allowance, every model call you make is billed in GitHub AI Credits (1 credit = $0.01 USD), at per-token rates that depend on which model you used and how big your context was.

Within 48 hours, Reddit, X, and GitHub's own community discussion thread were full of developers comparing 10x to 50x cost increases. One Redditor reported a jump from $29 to $750 a month. Another from $50 to $3,000. Some users with more measured workflows reported essentially no change. The variance is the story: the bill is now a function of how each individual developer actually uses the tool, and most developers had no idea what their usage profile looked like under the hood.

This site's recent coverage has been, in some sense, about what happens when machines end up on the receiving end of a similar meter — AWS AgentCore paying x402 endpoints, Circle's Agent Stack settling micropayments, Base MCP wiring LLMs into DeFi. The Copilot change is the human-facing rehearsal of the same shift, and it is teaching every payment developer something specific about how this economy is going to feel when it lands.

The Real Story Is Not the Price, It's the Variance

Look past the "GitHub raised prices" framing. The headline plans did not change. What changed is that per-developer billing variance just exploded by an order of magnitude. Under a flat subscription, the worst customer and the best customer both paid $10. Under per-token usage, the worst customer can easily pay 70x what the best one does — and neither of them can predict next month's bill from this month's, because their bill is a function of how much they happen to call premium models like GPT-5 or Claude 4.5 Opus inside the tool.

This is exactly the financial profile that payment developers have been building infrastructure for. Everything in the Keyrock report — sub-cent average transaction sizes, settlement variance across protocols, regulatory framework gaps — is the same shape of problem expressed at machine scale rather than human scale.

The interesting question is no longer "is consumption-based billing coming." It is here. The interesting question is what infrastructure makes it survivable for the people on the wrong end of the meter.

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

Base MCP Wires AI Agents Into On-Chain DeFi

Tom Wang — Tue, 02 Jun 2026 21:07:34 +0000

This week Coinbase's Ethereum Layer-2 network Base shipped one of the more consequential pieces of agentic-payment infrastructure of the year. Base MCP — a Model Context Protocol gateway — lets AI agents running on ChatGPT, Claude, Codex, or Cursor connect to a user's wallet, propose on-chain actions, and execute them after explicit user approval. It launches with first-class integrations for Uniswap, Morpho, and Moonwell, three of the most-used DeFi protocols on Base.

If you have been following this site's recent coverage — AWS AgentCore Payments, Circle's Agent Stack, Alipay's MCP server, MoonPay's MoonAgents Card — the pattern is now obvious. Every major payments and DeFi platform is shipping the same shape of product: an MCP server that lets a general-purpose LLM act as a frontend for their financial primitives. Base MCP is the first one that puts the entire onchain economy on the other end of that pipe.

What Base MCP Actually Does

The user-facing experience is the easy part. A Base Account user installs Base MCP into their AI client (ChatGPT, Claude, etc.) and authenticates via OAuth 2.1. From that point, conversational instructions like "swap $50 USDC for ETH on Uniswap" or "supply $1,000 USDC to the highest-yielding Morpho vault" parse into proposed transactions. The agent never sees the user's keys. Instead, Base Account opens a separate review window showing the exact transaction, and the user explicitly approves or rejects before anything moves.

Under the hood, three architectural choices are doing the heavy lifting:

Trusted execution environment (TEE) for key custody. Private keys are generated and stored inside a secure enclave that the AI agent — and the model provider — never directly access. The agent can propose a transaction; only the TEE can sign one, and only after the user's separate approval. This is the security model that has to work for any of this to be deployable at retail scale.
OAuth 2.1 for agent authorisation. Treating the AI client as a third-party application that the user can scope, revoke, and audit is the right primitive. It is also a notable departure from "paste a private key into a prompt", which is how a lot of early agent-DeFi demos worked.
MCP as the integration surface. Rather than every DeFi protocol building bespoke per-LLM integrations, MCP gives them one standard interface and the major LLM clients pick it up for free. This is the same dynamic that turned MCP into a real protocol over the last twelve months — and the reason Base picked it.

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

Tether and Georgia Launch a Non-USD Stablecoin

Tom Wang — Mon, 01 Jun 2026 10:45:22 +0000

Two days ago I argued that the headline finding of the Keyrock "Who Pays the Agent?" report — 98.6% of all AI agent settlement flowing through USDC — was the most important under-discussed risk in agentic commerce. The piece ended with the obvious question: who actually ships a credible non-USD stablecoin at the same operational quality? This week, Tether and the Government of Georgia answered it.

GEL₮ (GELT), a stablecoin pegged 1:1 to the Georgian lari, has been launched as the "official stablecoin of Georgia," with the support of Prime Minister Irakli Kobakhidze and under a regulatory framework already established by the National Bank of Georgia (NBG). It is one of the first joint efforts by a major stablecoin issuer and a sovereign government to put a national currency directly on digital-asset rails inside a purpose-built legal regime.

It is also the most interesting policy experiment in the stablecoin space since the GENIUS Act — and a useful contrast to the UK's HMT consultation and the White House EO on Fed access covered earlier this week. Three jurisdictions, three answers, all landing inside a fortnight.

What Georgia Actually Built

The piece worth studying is not the press release. It is the regulatory architecture sitting underneath it. Earlier in 2026, NBG Governor Natia Turnava signed an order establishing the legal framework for fiat-pegged stablecoins in Georgia. The framework requires:

Issuers to register with the NBG as virtual asset service providers.
100% reserve backing, held separately from company funds.
Defined redemption rights for holders.
Issuer oversight, AML/CFT obligations, and ongoing reporting.

In other words, Georgia did the unglamorous regulatory work first — a domestic VASP regime, reserve-segregation rules, redemption guarantees — and then invited an issuer to build on it. The official Tether announcement explicitly notes the framework was designed for compatibility with emerging US stablecoin regulation, including the GENIUS Act. That is not an accident. Georgia is positioning itself, deliberately, as a jurisdiction that you can issue a non-USD stablecoin from without future-proofing risk relative to where the major economies are heading.

For Tether, GEL₮ is also the first time the company has put serious effort behind a non-USD, non-EUR retail stablecoin tied to a sovereign currency. USDT remains the flagship. EUR₮ has existed for years but has never approached USDT volume. GEL₮ is something different in kind — a country-specific stablecoin, issued in formal partnership with the government of that country, designed to do for the lari what USDC and USDT have done for the dollar inside a much smaller, much tighter regulatory perimeter.

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

Fintech Devs May Get Fed Master Accounts

Tom Wang — Wed, 27 May 2026 09:18:13 +0000

On 19 May 2026, the White House signed an executive order titled "Integrating Financial Technology Innovation into Regulatory Frameworks." For anyone who follows US fintech policy at the headline level, it reads like another round of "regulators told to be friendlier to innovation." For anyone who actually builds payment infrastructure, it contains one paragraph that, if it lands as written, is the most consequential US fintech policy shift of the decade. The Federal Reserve has been asked to evaluate extending direct access to Reserve Bank payment accounts and payment services — what the industry calls master accounts — to uninsured depositories and non-bank fintechs. The Fed has 120 days to report back, putting the deadline around 16 September 2026.

If you have never had to integrate a US payment product against a sponsor-bank stack, that paragraph reads as plumbing. If you have, it reads as the most expensive engineering constraint in your architecture potentially being lifted.

This is the US counterpart to the UK regulatory work covered here recently — the FCA's CASS 15 safeguarding regime, the HM Treasury stablecoin consultation — and arguably a more aggressive intervention than anything happening in London right now.

What a Fed Master Account Actually Buys You

The Fed master account is the API to the US payment system. Holders can:

Settle directly through Fedwire and the Fed's National Settlement Service.
Originate and receive on FedNow and the legacy ACH network without an intermediary.
Hold reserves at the Fed rather than at a sponsor bank.
Get same-day, federal-funds-final settlement on transactions.

Today, the only entities that hold one are insured depository institutions — i.e., banks and credit unions. Every US fintech that moves dollars without a banking charter rides one of those master-account holders as a sponsor bank. That dependency is the single largest source of operational, latency, and economic drag in the US fintech stack. Sponsor banks gate KYC standards, set deposit caps, run their own batch windows, charge non-trivial bps, can change pricing on you, and — as Synapse's collapse painfully reminded the industry — can fail in ways that strand your customers' funds.

For a payment developer, removing the requirement to ride a sponsor bank is not an incremental optimisation. It collapses two whole layers of the stack into one and removes the most consequential third-party dependency in the architecture.

What the EO Actually Says (and Does Not Say)

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

The USDC Concentration Risk in AI Agent Payments

Tom Wang — Tue, 26 May 2026 13:20:54 +0000

For the better part of a year, every announcement covered on this site — AWS AgentCore Payments, Circle's Agent Stack, The Graph's x402 gateway, MoonPay's MoonAgents Card — has rested on a tacit assumption: that AI agents transacting in stablecoins is a real, measurable behaviour, not a deck slide. This week, the first serious data set arrived to test that assumption. The numbers are bigger than I expected, and the structural risk underneath them is more uncomfortable than the headlines suggest.

The new Keyrock report, "Who Pays the Agent?", produced with Coinbase, Tempo, and Virtuals, puts hard figures on the machine economy for the first time. Between May 2025 and April 2026, AI agents processed roughly 176 million on-chain transactions worth $73 million, at an average size of $0.31–$0.48. By the end of Q1 2026, more than 104,000 AI agents had registered across the major protocols. And 98.6% of every cent of that settlement flowed through a single stablecoin: USDC.

The first half of that story is the validation everyone in agentic commerce has been waiting for. The second half is the risk that, in Keyrock's own words, "nobody in the space is publicly discussing — we think they should be."

The Micropayment Thesis Survives Contact with Reality

The most important data point in the report is the size distribution. Roughly 76% of all agent transactions fell below Visa's $0.30 fixed fee threshold. That single statistic does more to settle the "are stablecoins really an agentic-payment primitive" debate than any keynote could. A clear majority of the activity is economically impossible on traditional card rails. The unit economics simply do not exist for a Visa or Mastercard tap on a 9-cent API call, even before considering reconciliation overhead.

By contrast, a USDC transfer on Base costs roughly $0.0001 — about 0.03% of a $0.31 transaction. The micropayment thesis was always credible in theory. Now there is a year of production data showing it works at scale: 176 million transactions, average ticket size in the cents, almost all of it on settlement infrastructure that traditional payments cannot price.

For any payment developer designing API or MCP-server billing, this number is the new floor under the conversation. You no longer have to defend whether per-call stablecoin pricing makes sense. You have to defend why your endpoint isn't offering it.

Why 98.6% USDC Is a Problem, Not an Achievement

Now the uncomfortable part. The same data set that vindicates the rail also reveals how dangerously thin its foundations are. 98.6% in a single stablecoin from a single issuer is not diversification expressing a free-market preference. It is concentration at the scale of a systemic risk.

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

Why UK Fintech Is Hiring Rust Developers in 2026

Tom Wang — Thu, 21 May 2026 17:26:59 +0000

Most of what this site has covered in May 2026 — Brazil's stablecoin ban, the FCA's CASS 15 safeguarding regime, AWS AgentCore Payments — has a quiet common thread. Every one of those stories ends with the same sentence: someone has to build the backend that makes this safe. This article is about who that someone is, and the language they increasingly reach for. In 2026, when a UK fintech sets out to build or rewrite the core of its payment infrastructure, the hiring brief more and more often says Rust developer.

The 2026 Rust Hiring Market, in Numbers

The market data tells a consistent story. In the US, Rust developer compensation in 2026 runs roughly $120,000–$185,000 for mid-level engineers and $170,000–$280,000 for senior systems roles. UK and London salaries scale below that in absolute terms but show the same shape: a clear premium over equivalent generalist backend roles, and a premium that has widened, not narrowed, over the past year.

The supply side is the interesting part. The Rust developer pool is growing fast — roughly doubling every 18 months — and yet roles still take a long time to fill. Application-layer Rust positions at mid-level typically take 4–7 weeks to fill; senior systems Rust roles take 8–14 weeks. When a talent pool is doubling and time-to-hire is still measured in months, that is not a supply problem. That is a demand problem outrunning a fast-growing supply.

For a rust developer in the UK, that asymmetry is the entire point. Demand for payments, open banking, and cross-border settlement engineers is expanding across London, Berlin, Dubai, and Singapore simultaneously, and the subset of those roles that specify Rust is the subset where the candidate, not the employer, sets the terms.

Why Payment Firms Are Rewriting Settlement Engines in Rust

The "why" is not fashion. It is a specific set of properties that map unusually well onto what a payment system actually needs.

Correctness the compiler enforces

A payment settlement engine has no acceptable failure mode. A double-spend, a lost transaction, a data race that corrupts a ledger balance — these are not bugs you patch next sprint, they are incidents with regulators attached. Rust's ownership model and type system eliminate entire categories of these failures at compile time: no null-pointer dereferences, no use-after-free, and — critically for a concurrent settlement engine — no data races. The compiler refuses to build code that shares mutable state unsafely. For a fintech, that is not a developer-experience nicety; it is a class of production incident that simply stops happening.

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email