DEV Community: Tom Wang

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

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