DEV Community: Tom Wang

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

Brazil's Stablecoin Ban Splits the Payment Rail

Tom Wang — Wed, 20 May 2026 16:03:32 +0000

For the last two months this site has tracked a single direction of travel: stablecoins moving from crypto curiosity to default settlement rail. Brazil's central bank just provided the counter-example every cross-border payment developer needs to internalise. On 1 May 2026, the Banco Central do Brasil ruled that electronic foreign exchange (eFX) providers may no longer use stablecoins — or any crypto — to settle overseas remittances. The ban takes effect on 1 October.

This is not a crypto crackdown. Individual Brazilians can still buy, hold, and transact in digital assets, and roughly 25 million of them do. It is something more surgical, and for anyone building payment infrastructure, more instructive: a regulator deliberately closing one settlement rail for one class of licensed firm, while leaving it open for another. The stablecoin rail did not get banned. It got split.

What Brazil Actually Did

The mechanics matter, because the mechanics are the lesson. The ruling draws a line between two regulatory categories:

eFX providers — the fintechs and payment firms that move money across borders for customers. From 1 October, they must settle cross-border flows through conventional foreign exchange transactions or non-resident real accounts. The stablecoin back-end is closed to them.
Licensed virtual asset service providers (VASPs) — and crucially, banks authorised as VASPs — can still use stablecoins for international payments, under the separate VASP framework that took full effect in February 2026.

So the exact same USDC transfer, settling the exact same Brazil-to-US corridor, is now legal or illegal depending entirely on the licence held by the firm initiating it. The token didn't change. The corridor didn't change. The regulatory wrapper around the sender did.

The central bank's reasoning is coherent. Almost 90% of crypto remittances originating in Brazil use dollar-pegged tokens like USDT and USDC. Brazil's crypto market moves an estimated $6–8 billion a month, around 90% of it stablecoin volume. Regulators worried that letting those tokens flow through a channel designed for highly supervised FX trades would erode tax collection, weaken monetary-policy transmission, and open anti-money-laundering blind spots. Whether or not you agree, the policy is internally consistent — and that is exactly what makes it a durable design constraint rather than a passing headline.

Why This Is a Routing Problem, Not a Policy Problem

If you build cross-border payment infrastructure, the temptation is to file this under "compliance will handle it." That is the wrong instinct. Brazil has just made jurisdiction-and-licence awareness a routing concern — something your settlement engine has to reason about on every single transaction.

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 Safeguarding Rules Reshape Payment Devs' Day

Tom Wang — Tue, 19 May 2026 09:53:03 +0000

Twelve days ago, on 7 May 2026, the FCA's new safeguarding regime for UK payments and e-money firms came into force. The headline rules sit inside the brand-new CASS 15 sourcebook chapter and they are the most prescriptive operational obligations the FCA has ever written for non-bank payment institutions. If you work as a UK fintech developer or payment developer inside a payment firm, an e-money issuer, or a platform that holds relevant customer funds, the engineering bar has just been raised — and the build that satisfies the new rules is the kind of unglamorous, deeply boring backend work that separates the firms that survive an audit from the ones that scramble through their first one.

This is the regulatory counterpart to the HM Treasury stablecoin consultation closing in three days. The Treasury piece sets out where UK payments regulation is going. CASS 15 is what is already in force this week.

What Actually Changed on 7 May

The old safeguarding regime relied largely on high-level principles. CASS 15 replaces that with prescriptive operational rules across five areas:

Daily reconciliation of safeguarded funds.
Monthly reporting confirming safeguarding practices and reconciliation outcomes.
Annual safeguarding audit by a qualified auditor (unless the firm has not been required to safeguard more than £100,000 of relevant funds at any point in the preceding 53 weeks).
Resolution packs that allow safeguarded funds to be distributed quickly in a wind-down.
Third-party due diligence on safeguarding banks, custodians, and account providers.

The piece that puts the largest demand on engineering teams is the daily reconciliation requirement. It is the most operationally specific obligation in the regime and the one that, in practice, will define whether a firm's safeguarding posture is real or theatrical.

"Six a Day" — the Reconciliation Obligation in Practice

The FCA requires multiple types of reconciliation on every business day (excluding weekends and UK public holidays):

An internal check that the firm's "safeguarding resource" — the funds actually held in segregated accounts or invested in relevant assets — equals its "safeguarding requirement", the amount the rulebook says it should be holding.
A D+1 internal confirmation that relevant funds received on day D have, by close of business the next business day, landed in a designated safeguarding account or relevant asset.
An external comparison of the firm's own internal records against third-party records: statements from safeguarding banks, statements from account providers, and confirmations from authorised custodians.

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

MoonPay Launches AI Agent Mastercard in UK

Tom Wang — Mon, 18 May 2026 14:02:14 +0000

For the past six months, the agentic-payments story has been about machines paying other machines — APIs, MCP servers, on-chain data feeds, paywalled subgraph queries. On 1 May 2026 MoonPay shipped the missing piece: a virtual Mastercard that lets an AI agent walk into the existing card-acceptance network and spend stablecoins at any of the 100-million-plus merchants that already take Mastercard. The UK is one of the two launch markets, alongside LATAM, with US and EU rollout flagged for the coming months.

MoonAgents Card is the first credible bridge between the new on-chain agent economy and the off-chain economy that humans actually live in. For a UK payment developer or fintech developer evaluating where agentic commerce becomes mass-market, this is the launch worth studying.

How MoonAgents Card Actually Works

The architecture is the part that matters. MoonPay did not build a closed wallet, take custody, or recreate the existing crypto-debit-card pattern of "pre-load the card from your wallet." Custody stays with the user.

When an agent or human initiates a purchase:

The card transaction lands at Monavate, MoonPay's regulated card issuer.
A smart contract authorisation against the user's wallet is invoked at point-of-purchase.
Stablecoins are converted to fiat at the moment the transaction clears.
The merchant sees a normal Mastercard authorisation.

The user authorises a smart contract to access stablecoin balances at transaction time, not in advance. Approvals are revocable at any moment. Declined transactions return funds immediately to the wallet. Hardware signing through Ledger means agent security has a physical root of trust the user can pull at any time.

That last point is the one I find most interesting. The failure mode every payment engineer fears with autonomous agents is the same one that haunts open-banking VRP design: a compromised agent draining a wallet against an over-broad authorisation. MoonPay's design pushes the authorisation event down to the transaction itself, with the hardware key in the loop. It is structurally closer to how a corporate card with real-time controls works than to how a typical crypto debit card works.

The Developer Surface

The thing that gives this announcement weight, rather than just being another fintech launch, is the CLI:

npm install -g @moonpay/cli
mp card issue --wallet your-wallet-name

That is the entire path from "developer with an agent" to "agent with a Mastercard". MoonPay says its CLI has processed over four million tool calls since launch — the developer flywheel is already turning before the card product reached general availability.

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 Graph x402 Gateway: USDC Per-Query Goes Live

Tom Wang — Sun, 17 May 2026 22:24:07 +0000

On 12 May 2026, The Graph quietly shipped one of the more important agentic-payments milestones of the year: the Graph Gateway now accepts x402 USDC payments on a per-query basis, with no API key, no account, and no contract negotiation. An AI agent that holds USDC on Base can simply ask the gateway for on-chain data, get an HTTP 402 Payment Required, settle, and receive the response — typically in seconds.

This is the part of the agentic stack that gets less press than AWS AgentCore Payments but is arguably more consequential for a payment developer building real systems. It is x402 stretching from "specification with backers" into "live infrastructure billing real money for real queries."

What Actually Shipped

The Graph exposed a new /api/x402/ interface on its existing gateway. The flow is the same x402 dance HTTP has formally supported since 1997 and that Coinbase rehabilitated in 2025:

The client sends a request to the x402 endpoint.
The gateway returns HTTP 402 Payment Required with pricing information in response headers.
The client signs and broadcasts a USDC payment on Base mainnet (or Base Sepolia in test).
The client retries the request. The payment itself serves as authentication.
The gateway returns the requested subgraph data.

There is a new payments SDK, plus support for any x402-compatible tooling. The crucial detail is in step 4: there is no separate auth layer. No API key to leak, rotate, or rate-limit. Possession of a settled USDC transfer is the credential.

For developers wiring up an AI agent to read DEX pair history, NFT metadata, governance events, or token information across the multiple chains The Graph indexes, the integration surface area collapses to roughly: a wallet, a USDC balance, and the standard payment middleware.

Why "Pay-Per-Query" Changes the Backend Calculus

The dominant model for on-chain data access today is the same one we use for everything else on the web: provision an API key against a usage tier, monitor consumption, deal with overage either by throttling or by an awkward invoicing conversation later. That model works tolerably for a human-built application with predictable traffic. It breaks down badly for autonomous agents whose query volume is bursty, machine-paced, and unpredictable.

A pay-per-query gateway sidesteps the entire problem. The agent's wallet balance is its rate limit. The settlement event is its receipt. There is no commercial relationship to maintain, no key to provision, no quota to top up. From a backend perspective, billing collapses from a recurring revenue function into a function of 200-response volume.

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 Stablecoin Rules Reach Fintech Devs This Week

Tom Wang — Fri, 15 May 2026 11:06:01 +0000

Friday 22 May 2026 is the quietest deadline most UK fintech engineers have probably never heard of. That is the day HM Treasury closes consultation on a draft statutory instrument amending the Financial Services and Markets Act 2000 (Cryptoassets) Regulations 2026 — a short, technical document that, if the wind blows the right way, finally folds stablecoins into the same regulatory perimeter as everything else a payment developer touches in the UK.

If you build payment infrastructure for a living, this is one of the more consequential weeks of the year. The shape of the UK stablecoin market for the next five years is being decided right now, on a public mailing address, with a deadline most teams are about to sleepwalk past.

What HM Treasury Is Actually Proposing

The April 21 package, sitting alongside the FCA's announcement that stablecoin payments are a 2026 growth priority, has a clear thrust. It would carve UK-issued qualifying stablecoins (UKQS) out of the cryptoasset regulated activities of "dealing as principal", "dealing as agent", and "arranging deals" — the three perimeters that have made it operationally painful to treat a UK stablecoin like a payment instrument.

In plain English: today, accepting a sterling-pegged stablecoin as a payment method risks being treated as a regulated cryptoasset activity. Tomorrow, under the proposed amendments, it could be treated as what it actually is — a payment. UKQS lending and borrowing stays inside the cryptoasset perimeter, which preserves the FCA's hand on consumer-protection issues, but the day-to-day acts of paying and being paid get the regulatory weight they should have had from the start.

The wider government direction, signalled in the same package, is to consolidate payment services and electronic money regulation into a single regime that covers traditional payments, tokenised deposits, and stablecoins together. The FCA gains expanded powers over Open Banking. The Payment Systems Regulator gets folded into the FCA. AI agent payments are explicitly named as something the new framework is meant to accommodate.

Why This Matters for UK Payment Developers

Three concrete things change for the average UK fintech developer if this lands as drafted.

Stablecoin acceptance becomes an integration problem, not a legal problem. Today, the cleanest path to taking a stablecoin payment in the UK is usually to route it through an offshore acquirer and convert to fiat before it touches your books. That adds latency, FX cost, and reconciliation pain. Under the new perimeter, a UK-issued sterling stablecoin can sit in your settlement flow the way a Faster Payment does — instantly, finally, with the same regulator on both legs.

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

AWS Launches Stablecoin Payments for AI Agents

Tom Wang — Thu, 14 May 2026 18:40:04 +0000

Amazon Web Services has shipped the missing piece of the agentic stack. On 7 May 2026, AWS introduced Amazon Bedrock AgentCore Payments in preview — the first managed payment capability purpose-built for autonomous AI agents, developed with Coinbase and Stripe. For any fintech developer or payment developer who has spent the last year wiring agents into brittle, hardcoded billing flows, this is the moment the plumbing became a platform primitive.

The headline is simple: an AI agent running on Bedrock can now encounter a paid resource, settle the bill in USDC stablecoin, and carry on — all inside its execution loop, with no human in the path. The interesting part, as always, is in the protocol details.

How AgentCore Payments Works Under the Hood

The payment flow is built on x402, the HTTP-native payment standard Coinbase open-sourced and which recently joined the Linux Foundation. The mechanics are pleasingly boring, which is exactly what you want from payment infrastructure:

The agent sends a request to a paid endpoint.
The endpoint replies with an HTTP 402 Payment Required.
AgentCore's payment processor authenticates against the configured wallet.
It executes a stablecoin payment via the x402 protocol negotiation.
It attaches cryptographic payment proof to the original request.
The endpoint returns the content, and the agent continues — typically in well under a second.

Developers enable this on an existing agent through the AgentCore SDK or console, or by calling the payments service APIs directly via the AWS CLI and SDKs. It also integrates with agent frameworks like Strands Agents. Crucially, there is a service-discovery layer: the Coinbase x402 Bazaar MCP server is exposed through the AgentCore gateway, giving agents a curated, searchable list of x402 endpoints they can discover and pay for on demand.

Two Wallet Models: Coinbase and Stripe Privy

AgentCore Payments offers a choice of payment connection. Developers can attach a Coinbase wallet, funded with stablecoins, or a Stripe Privy wallet, which supports both stablecoin and fiat funding via debit card. Both abstract away the hardcoded integration work that has made agent commerce painful until now. Brian Foster of Coinbase framed the rationale bluntly: agents "need money that's built for the internet — programmable, always on, and global." Henri Stern of Privy added that "for agents to become meaningful economic actors, they need a way to hold and spend money."

The Governance Layer Is the Real Story

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

NatWest's UK Fintech Class of 2026 Goes Agentic

Tom Wang — Wed, 13 May 2026 08:52:00 +0000

NatWest revealed its 2026 FinTech Programme cohort yesterday, and the line-up is the cleanest snapshot of where UK fintech is actually placing its bets. Every one of the eight companies is AI-native; four are explicitly agentic. For a fintech developer UK, AI agent developer UK, or payment developer looking at where the next hiring round of UK fintechs concentrates, this list is more useful than another quarter of high-street bank earnings.

The selection also signals what NatWest — a systemically important UK bank with sprawling open banking, retail, and corporate operations — thinks AI is for in 2026. Not chatbots. Not generic copilots. Treasury orchestration, autonomous compliance, debt collections, and the customer vulnerability surface most banks would rather not talk about.

The Eight Companies, and Why They Were Chosen

A quick read of the cohort, with the part that matters to engineers building in this space:

Round Treasury — agentic treasury and payments platform connecting 2,000+ banks for unified banking, liquidity, automations, payments, and FX in real time. This is the clearest example in the cohort of agent orchestration sitting above multiple bank rails. The architecture has to handle latency, idempotency, and reconciliation across thousands of bank APIs simultaneously.
Gradient Labs — AI agents for customer support and operational workflows, with embedded guardrails. The "embedded guardrails" framing is the part to study; a regulated bank cannot ship an agent without scope, policy, and observability baked in at the framework level.
Murphy AI — AI-first operating system for debt collections with autonomous agents. Collections is one of the most regulated, contentious customer interactions a bank handles. Autonomous agents here have to navigate compliance and customer vulnerability without producing a Financial Conduct Authority headline.
Condukt — agentic compliance platform with automated decisioning and business onboarding. KYB at speed, with audit trails dense enough to survive a regulator's review.
Aveni — AI platform combining proprietary language models for customer engagement and real-time compliance. A reminder that "fintech AI" in 2026 increasingly means a vertically integrated language model plus the surrounding compliance surface, not a thin OpenAI wrapper.
DeepFlow — cross-silo orchestration layer for financial crime and risk operations. The unglamorous integration layer that most banks need before they can deploy agents at all.
Empath_AI — vocal biomarker tech to identify and support vulnerable customers. A reminder that "AI in banking" is not only commercial — the FCA's vulnerable customer framework is a real engineering requirement, and there is now a venture-backed company purpose-built for it.
Galveston Group — AI-native geopolitical intelligence mapped to portfolio risk. Risk teams reading agentic outputs rather than week-old PDFs.

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

Circle Agent Stack: USDC for Machine Payments

Tom Wang — Tue, 12 May 2026 10:51:55 +0000

The agentic commerce stack got its first serious USDC-native answer today. On 12 May 2026 Circle launched Agent Stack — a five-component product suite where the customer is explicitly an AI agent, not a human or a developer. CEO Jeremy Allaire framed it directly: "financial infrastructure has historically been built for people, with manual onboarding, approvals, and payment flows that were never designed for software acting on its own." For any fintech developer UK, AI agent developer UK, or crypto developer UK trying to pick a horse in the agent payment race, Circle has now put itself in direct competition with Coinbase's x402, Solana's Pay.sh, and AWS Bedrock AgentCore Payments.

The release lands on top of an already crowded week. AWS shipped AgentCore Payments with Coinbase and Stripe; Solana and Google launched Pay.sh; MoonPay rolled out MoonAgents Card on Mastercard. Five competing reference designs for machine-to-machine payments are now in production within a fortnight of each other.

What Circle Actually Shipped

The Agent Stack has five components, each addressing a specific bottleneck for autonomous agent commerce:

Circle CLI — a command-line interface for both developers and agents to build on Circle's infrastructure. The framing matters: the CLI is for the agent, not just for the human operator. An agent invoking shell commands against a typed Circle API is a first-class workflow.
Agent Wallets — permissionless, policy-controlled wallets that hold USDC and execute transactions inside preset guardrails. The agent acts; the wallet enforces scope.
Agent Marketplace — a curated directory where agents discover and programmatically purchase services. Service providers list endpoints with pricing, agents query, negotiate, and pay.
Nanopayments — gas-free USDC transfers as small as $0.000001. One-millionth of a dollar, per call, at machine speed. This is the line that ACH, card networks, and Lightning all struggle to cross.
Circle Skills — the component Circle is keeping closest to its chest; an agent-skill abstraction sitting above wallets and marketplace.

Backing the whole thing is Circle's existing Payments Network ($8.3B annualised volume) and the parallel Arc chain (Circle's payments-optimised L1, separately funded by a $222M token presale). Agent Stack is the execution layer for what Circle is positioning as an "economic OS for the internet."

Why This Is a Different Bet from x402, Pay.sh, and AWS AgentCore

The agentic payment race has split into four reference designs, each making a different bet:

Coinbase x402 (Linux Foundation) — open HTTP-native protocol, 200ms settlement on Base, vendor-neutral coalition (AWS, Google, Stripe, Visa, Mastercard).
Solana Pay.sh (Solana Foundation + Google Cloud) — open-source API payment gateway, USDC on Solana, deep Google Cloud integration.
AWS Bedrock AgentCore Payments (AWS + Coinbase + Stripe) — managed payment infrastructure inside Amazon's agent runtime, x402-based.
Circle Agent Stack (Circle) — vertical USDC-native stack with wallet, marketplace, CLI, nanopayments, and an in-house chain.

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

Western Union's USDPT Goes Live on Solana

Tom Wang — Mon, 11 May 2026 11:57:12 +0000

When a 175-year-old correspondent banking incumbent issues its own stablecoin, the story is not really about the coin. On 4 May 2026 Western Union announced USDPT, a US dollar-backed payment stablecoin issued by Anchorage Digital Bank on Solana, with Fireblocks providing the institutional infrastructure. The Philippines and Bolivia get the first rollout. The "Stable by Western Union" consumer product is queued for 40+ countries this year. For any fintech developer UK, crypto developer UK, or payment developer building cross-border payouts, this is the moment legacy remittance stopped being a defensible business and became a stack to disassemble.

The previous week was already heavy with stablecoin moves — Meta, Visa, Stripe Sessions, Banking Circle, KFTC. Western Union takes the pattern somewhere harder to ignore: the incumbent that built its empire on correspondent banking is now using a public chain to settle around it.

What Western Union Actually Built

The architecture is, again, deceptively simple — and that simplicity is the strategic move.

Token — USDPT, US dollar-denominated, backed 1:1 by USD reserves.
Issuer — Anchorage Digital Bank N.A., the first federally regulated US crypto bank. This matters: Anchorage holds an OCC charter, so USDPT is issued by a federally chartered institution, not a non-bank trust company. Regulatory framing is different to USDC or USDT.
Settlement chain — Solana. Sub-second finality, sub-cent fees, the same chain Meta picked for creator payouts and that Visa added to its settlement pilot this month.
Custody and orchestration — Fireblocks. Institutional-grade key management with MPC, policy engine, transaction monitoring — exactly the surface a bank needs to defend in a regulator's audit.
Rollout — Philippines and Bolivia first. These are not arbitrary; they are two of Western Union's largest remittance corridors, where correspondent banking takes the biggest cut.

The plan is to use USDPT as a 24/7 always-on settlement asset between Western Union and its global agents, plus a consumer-facing product (Stable by Western Union) for 40+ countries in 2026.

Read between the lines: Western Union has been paying correspondent banks for treasury settlement for over a century. USDPT lets it move dollars between its own agent network on a public chain instead. The savings flow back to Western Union, the customer experience gets faster, and the company keeps the regulatory perimeter Anchorage provides.

Why Solana, and Why It Is a Pattern Now

Western Union picking Solana is the third major incumbent to do so this month, after Meta's USDC creator payouts and Visa adding Solana to its settlement pilot. The reasons are by now boringly consistent:

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