DEV Community: Tom Wang

Sanctions Screening API: OFAC vs UK vs EU Lists

Tom Wang — Thu, 29 Oct 2026 08:55:41 +0000

In August 2026 OFSI fined Citibank's London branch £4,732,830.58, and part of the case came down to three letters. The bank's screening system did not treat "PAO Sovcomflot" in its customer records as a match for "Sovcomflot" on the sanctions list, so 32 accounts stayed unrestricted and 328 transactions worth about £5.4 million went through.

Most screening failures look like that: a legal-form prefix, a transliteration, a list update that arrived nearly fourteen hours late. The pages ranking for "sanctions screening API" are mostly vendor product pages that skip the official download URLs, the thresholds open-source engines ship with and the licence terms on the data. The counts below come from the OFAC, UK, EU and UN files as I downloaded and parsed them on 29 October 2026.

How Does Sanctions Screening Work in Payments?

A screening system keeps a local copy of one or more government lists, compares names (and ideally dates of birth, passport or IMO numbers) against it, and sends anything above a score threshold to an analyst who decides whether the hit is real.

Most firms screen at two points. Customer screening runs at onboarding and again whenever a list changes, because a customer who was clean on Monday can be designated on Tuesday. Payment screening checks every party in a transfer, intermediary banks and free text included, before the money moves. The hard part is the comparison: names are not identifiers, and every list writes them differently.

OFAC SDN List vs UK Sanctions List vs EU Consolidated List

The four lists a UK or EU payment firm usually screens differ in size, in scope and in what counts as an entry.

	OFAC SDN	UK Sanctions List	EU consolidated (FSF)	UN consolidated
Entries, Oct 2026	19,484	6,420	6,269	1,007
Individuals	7,529	4,070	4,490	733
Ships and aircraft	1,568 vessels, 342 aircraft	683 ships	none	none
Formats	XML, advanced XML, CSV, fixed-width, PDF	XML, CSV, ODS, ODT, HTML, TXT, PDF	XML, CSV, PDF	XML
Access	Public, User-Agent required	Public	Public token in the URL	Public, one-hour signed redirect
Entry ID	integer `uid`	`UniqueID`, e.g. `RUS1653`	`logicalId`, `euReferenceNumber`	`REFERENCE_NUMBER`, `DATAID`

OFAC's list is the largest because it spans 72 programmes, with 6,346 entries under Russia EO 14024 alone, and carries 1,075 digital currency addresses. Only 5,743 UK entries impose an asset freeze: 668 of the 683 ships are under shipping sanctions only. Alert on every UK entry and your payments queue fills with vessels that freeze no funds. The EU file has no ship type at all.

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

Merchant Category Codes (MCC): Visa vs Mastercard

Tom Wang — Wed, 28 Oct 2026 08:32:39 +0000

MCC 5967 tells a Visa issuer that the merchant sells adult content. In Mastercard's latest public code booklet, dated April 2024, the same four digits still mean inbound telemarketing. Visa renamed the code between its April 2024 and April 2025 manuals, and this month it moved escort services into it too.

The merchant category code rides on every card authorisation. It sets US interchange, decides whether a UK credit card prices the payment as a cash advance and whether a bank's gambling block fires, and can leave an acquirer owing Visa USD 100,000 a month. The pages ranking for "merchant category code" are code lists and glossaries. Most get wrong who assigns the code, and none maps it to the API fields that carry it. Rules here were checked against Visa's Merchant Data Standards Manual (October 2026), the Visa Core Rules (18 April 2026) and PSP OpenAPI specs on 28 October 2026.

What Is a Merchant Category Code (MCC)?

An MCC is a four-digit number that classifies a merchant outlet by what it mainly sells: 5411 for grocery stores, 5812 for restaurants, 4511 for airlines. It travels with every card transaction. In the authorisation request it sits in ISO 8583 data element 18 (Merchant Type). In Mastercard's clearing file it goes in DE 26 (Card Acceptor Business Code), and an invalid value gets the presentment rejected with error 0531. The ISO 20022 card messages carry it as MrchntCtgyCd in cain.001, typed ISO18245MerchantCategoryCode with the pattern [0-9]{4}.

Of the few merchant fields an issuer sees on an authorisation, the MCC is the only one built for software to reason about. Fraud models, spend controls and rewards engines all lean on it.

Who Assigns a Merchant Category Code?

The acquirer. Not the merchant, not the card issuer and not the scheme. Visa Core Rules section 1.5.1.11 says an acquirer "must assign to a Merchant Outlet the MCC that most accurately describes its business". Mastercard Rules 5.8.1 requires the code to reflect the primary business and gives Mastercard the final word in a dispute.

Public explanations drift here, including from banks. Nationwide's gambling-support page says gambling companies assign their own codes. A Financial Ombudsman decision describes the code as applied by the merchant. Santander's cashback terms say Mastercard assigns them. What actually happens: the merchant describes its business at onboarding, and the acquirer, or a payment facilitator acting for it, picks the code and answers for 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

CCTP V2 vs USDT0: Moving Stablecoins Cross-Chain

Tom Wang — Tue, 27 Oct 2026 08:23:40 +0000

Circle starts cutting CCTP V1 burn limits on 31 October 2026 and pauses the V1 contracts on 1 December. From then on, any integration still calling V1 stops moving USDC between chains. Some explainers that still rank give a July date, and one of the most complete third-party guides has the finality thresholds the wrong way round.

CCTP V2 is the replacement, and it changes more than contract addresses. Nonces are assigned off-chain, a transfer can settle before finality if you pay for it, and the burn message can carry hook data that CCTP never executes. On 27 October 2026 I pulled every route's fee from Circle's API and decoded three hours of live burns on Base. The numbers below come from that, followed by a comparison with USDT0, Chainlink CCIP and Wormhole NTT.

What Is CCTP V2 and How Is It Different From V1?

CCTP (Cross-Chain Transfer Protocol) burns native USDC on the source chain and mints it on the destination. There is no liquidity pool in the middle and no wrapped token at the end. Circle's attestation service, Iris, signs a message once the source chain reaches the finality you asked for, and the destination contract mints against that signature.

It is less a bridge than Circle's own mint authority behind an API. The only party you trust is the one you already trust by holding USDC.

	CCTP V1	CCTP V2
Nonce	`uint64`, in the source-chain event	`bytes32`, assigned off-chain by Circle
Finality	Hard finality only	Confirmed (Fast) or finalised (Standard)
Protocol fee	None	Fast 0–13 bps, Standard free
Hooks	None	`depositForBurnWithHook` carries `hookData`
Expiry	None	Fast messages get an `expirationBlock` about 24h out
Status	Limits cut from 31 Oct 2026, paused 1 Dec 2026	Current, about 30 domains

The nonce change is the one that breaks indexers. On the source chain, V2 emits zeros where the nonce, finalityThresholdExecuted, feeExecuted and expirationBlock will go, and Circle fills them in when it signs. The V2 DepositForBurn event has no nonce at all. If your V1 reconciliation keyed transfers on a nonce read from the burn event, there is nothing left to key on. Key on source domain plus transaction hash, which is what the attestation API takes anyway, and store eventNonce once Iris returns 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

Web Bot Auth vs Visa TAP: How to Verify AI Agents

Tom Wang — Mon, 26 Oct 2026 08:39:45 +0000

Copy the signed request from Visa's Trusted Agent Protocol spec into a unit test, run it through an Ed25519 verifier, and it fails. Mastercard's Agent Pay example fails too. Both reuse a signature from an IETF test vector that signs a different message, and both set a 60-minute validity window that breaks the 8-minute limit each network tells merchants to enforce.

Web Bot Auth, Visa TAP and Mastercard Agent Pay are how an AI agent proves who it is to a merchant's website in 2026. All three sit on RFC 9421 HTTP Message Signatures, and they disagree on tags, windows, nonces and the syntax of a single header. This guide shows a real signed request, the signature base a verifier rebuilds, and verification code that copes with all three.

What Is Web Bot Auth?

Web Bot Auth gives bots and AI agents a cryptographic identity at the HTTP layer. The agent operator signs each request with a private key and publishes the public key in a directory. The site verifies the signature and knows which operator sent it, with no shared secret and no change to TLS.

It is still a draft. The IETF chartered the webbotauth working group on 23 October 2025, and its only adopted document is draft-ietf-webbotauth-httpsig-protocol-00, published 1 September 2026 by authors from Cloudflare and Google. Adoption was contested: the poll at IETF 126 came out 22 yes, 6 no, 5 no opinion.

Deployment has run ahead of the standard anyway. Cloudflare, Akamai, AWS WAF, Vercel and HUMAN verify signatures; ChatGPT's cloud browser, Google-Agent and AWS AgentCore Browser send them. On 23 October 2026 IANA registered ml-dsa-44, ml-dsa-65 and ml-dsa-87 for HTTP Message Signatures, though Cloudflare and AWS WAF still accept Ed25519 only.

How Does Web Bot Auth Work? A Signed Request, Line by Line

These headers are the current draft's own example (Appendix E.2.1), with line wrapping removed:

Signature-Agent: agent2="https://signature-agent.test"
Signature-Input: sig2=("@authority" "signature-agent";key="agent2");created=1735689600;keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U";alg="ed25519";expires=4889289600;nonce="n9p433xm+NJ3ph3upfBIGmsuwHw387YV7Q/F+6BSpGCVjYCqQw6rznNA8PVVLySrAWsv0hQtFioQb6E1YsauiA==";tag="web-bot-auth"
Signature: sig2=:RdNFx5Bj6au3YgAMQL/RzmUlZE8QZLIaXGRpw985hWnwPfMxT228NMk6ehRS1PSl4e8PhbNZACSanGdhEwYCCg==:

The verifier does not check the headers directly. It rebuilds a signature base, one line per covered component, with @signature-params required as the last line:

"@authority": example.com
"signature-agent";key="agent2": "https://signature-agent.test"
"@signature-params": ("@authority" "signature-agent";key="agent2");created=1735689600;keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U";alg="ed25519";expires=4889289600;nonce="n9p433xm+NJ3ph3upfBIGmsuwHw387YV7Q/F+6BSpGCVjYCqQw6rznNA8PVVLySrAWsv0hQtFioQb6E1YsauiA==";tag="web-bot-auth"

Those bytes verify against the RFC 9421 Appendix B.1.4 Ed25519 test key. I checked. The key is public, so the vector is for tests only.

What the draft requires of a signer:

Coverage: at least one of @authority or @target-uri, plus the Signature-Agent member that belongs to this signature.
Parameters: created, expires, a keyid that "MUST be a base64url JWK SHA-256 Thumbprint", and tag set to web-bot-auth.
Expiry: "RECOMMENDED that expiry be no more than 24 hours".
Nonce: no requirement. Earlier versions asked for a unique 64-byte nonce; the WG draft dropped it.
Algorithms: anything registered except shared-secret HMAC, which is banned.
Keys: a JWKS at /.well-known/http-message-signatures-directory, media type application/http-message-signatures-directory+json, HTTPS only. Failed lookups may be cached for at most five minutes. There is no revocation.

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

AFT vs OCT: Visa Direct and Mastercard Send Rules

Tom Wang — Sun, 25 Oct 2026 08:35:16 +0000

A US Visa issuer has 60 seconds to make a domestic Fast Funds payout spendable. Everywhere else the Fast Funds clock is 30 minutes, and for a UK credit card Fast Funds is not mandatory at all: the issuer only has to post the money by the end of the business day. If your product says "instant payout", the card's country and type decide whether that is true.

Account Funding Transactions (AFTs) pull money off a card to fund something. Original Credit Transactions (OCTs) push money onto a card. The pages ranking for them are glossaries that define the terms and stop; none gives the codes, scheme rules or API fields a payout flow needs. Scheme rules here are from the Visa Rules edition of 18 April 2026, and PSP fields were checked against official docs and OpenAPI specs on 25 October 2026.

What Is an Account Funding Transaction (AFT)?

An AFT pulls funds from a Visa card to load another account: a wallet, a prepaid card, a brokerage account, or the first leg of a person-to-person transfer. It looks like a purchase to the cardholder, but it is not one. Visa's rules (section 7.4.1.1) say an AFT must not be a payment for goods or services or the funding of a merchant account.

Visa makes AFT coding compulsory for a specific list:

reloading prepaid cards
card-absent funding of P2P and account-to-account transfers
funding disbursements from Visa corporate and business debit cards, such as payroll
funding stored value and staged digital wallets, unless it is back-to-back funding
buying liquid and cryptocurrency assets

The footnote is the part UK teams miss. For the card-absent condition, Visa adds "In the Europe Region: For all Merchants". In the UK and EEA, a wallet top-up at a terminal still has to be an AFT.

Every AFT must carry the AFT indicator and the correct business application identifier (BAI) in both the authorisation and the clearing record. Debt repayment was split by region from 25 July 2026: it must be an AFT in Asia Pacific, CEMEA and most of Latin America, and must not be one in Canada, Europe, the US, Chile and Puerto Rico. A UK lender taking card repayments should not flag them as AFTs.

What Is an Original Credit Transaction (OCT)?

An OCT pushes money onto a card. Visa defines it as a credit that "does not require a prior purchase", except when it is used as a Faster Refund. That is the key difference from a refund, which has to reference an original sale. Payroll, marketplace seller payouts, insurance claims and gambling winnings all travel as OCTs.

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

8-Digit BIN Lookup: What Stripe and Adyen Return

Tom Wang — Sat, 24 Oct 2026 07:32:11 +0000

In its March 2022 position paper on 8-digit BINs, Visa reported that "tables purchased off the internet are roughly 30% accurate." If your checkout decides debit or credit, consumer or commercial, UK or foreign from a downloaded list keyed on six digits, that is the quality of data behind the decision.

The pages ranking for "8 digit bin" stop at the April 2022 deadline, some still in the future tense, and none maps BIN data to what payment APIs actually return. This guide does, along with the PCI limits by card length and the UK rules that depend on card type. Documentation was checked on 24 October 2026.

What Is an 8-Digit BIN, and Is a BIN the Same as an IIN?

In practice, yes. IIN (issuer identification number) is the term ISO/IEC 7812-1 uses, BIN (bank identification number) is the older industry name, and the schemes use both. It is the leading digits of the card number, and it identifies the issuer and, through the scheme's tables, the card product.

The fifth edition of ISO/IEC 7812-1, published in January 2017, lengthened the IIN from six digits to eight. ISO's announcement gave one reason: "there is expected to be a shortage in the available supply of IINs." Every existing six-digit IIN became "a block of a hundred eight-digit IINs", and an issuer with an eight-digit IIN must issue card numbers of at least ten digits, with 19 still the maximum. The American Bankers Association is still the registration authority.

Two consequences matter to engineers. The card number does not get longer: Visa's FAQ says PANs "will remain the same at 16 digits", so the issuer prefix takes two digits from the account number. And six-digit BINs did not disappear. Issuers can keep them, split them or run both, so any system that assumes one fixed length is wrong for some share of cards.

When Did Visa and Mastercard Move to 8-Digit BINs?

Visa endorsed the standard in 2017 and named 22 April 2022 "its final effective date". From then, acquirers and processors had to support eight-digit issuing BINs. Issuers never had to migrate: Visa's requirements say they "have the option to expand any or all of their current six-digit issuing BINs".

According to Deloitte's 2020 readiness paper, Mastercard planned to issue eight-digit BINs after April 2022 with no end date for six-digit ones. Discover's September 2026 IIN table defines the IIN as "the first six (6) or eight (8) digits" and lists every range it carries, JCB and UnionPay included, in eight-digit form. American Express stays on 15-digit cards, which PCI still caps at first six, last four.

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

OCC GENIUS Act Final Rule: 2-Day Redemption

Tom Wang — Fri, 23 Oct 2026 07:25:06 +0000

Under US rules, a stablecoin redemption now counts as done when the issuer sends the dollars, not when it burns the token. That is one sentence in the 721-page final rule the Office of the Comptroller of the Currency released on 21 October, and for anyone building on USDC or PYUSD it matters more than the yield row that has dominated the coverage.

The rule creates a new 12 CFR Part 15, "Payment Stablecoins", and it appears in the Federal Register today at 91 FR 67000. It takes effect on 18 January 2027, the date the GENIUS Act itself switches on. It is the first final rule from a primary federal stablecoin regulator. The Federal Reserve's two proposals are open for comment until 30 November, and the FDIC has not finalised anything yet.

What Does the OCC GENIUS Act Final Rule Cover?

Part 15 covers national banks, federal savings associations, federal branches, foreign issuers, nonbanks seeking Federal qualified issuer approval, and state issuers under OCC enforcement. The OCC's impact analysis counts 39 entities, including at least 12 it does not supervise today, and puts baseline 2027 issuance at $272.3bn. For scale, USD stablecoins stand at roughly $303bn this week on DefiLlama, with USDT at $182.5bn and USDC at about $72bn.

Anti-money laundering and sanctions rules are not in it. They sit in separate proposals from the OCC and from FinCEN and OFAC, so the wallet-screening obligations developers care about most are still not final.

GENIUS Act Reserve Requirements: 5% Cash and a 40% Cap

Eligible reserves are cash, Fed balances, demand deposits, Treasuries with 93 days or less to run, overnight repo against them, government money market funds, and tokenised versions of these. The OCC drew about 328 comments on its February proposal, and the changes since are where the policy shows.

Requirement	Proposal (Feb 2026)	Final rule (Oct 2026)
On-demand deposits or Fed balances	10% minimum	5% minimum
Single counterparty	40% cap	40% cap, excluding US government, custodians and centrally cleared repo
Liquidity safe harbour	30% weekly liquidity, 20-day maturity cap	Dropped
Withdrawing surplus reserves	Monthly	Any time, after due diligence
Capital	$5m floor, bank-style CET1/AT1 tiers	$5m floor, GAAP equity less intangibles
Operational backstop	12 months of expenses	12 months of expenses, up to half in subordinated debt
Redemptions above 10% in 24 hours	Automatic 7-day extension	Notify OCC within 24 hours, may request extension

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

Visa Account Updater vs Mastercard ABU Explained

Tom Wang — Thu, 22 Oct 2026 08:00:21 +0000

Visa's own VAU FAQ puts a number on card churn: on average, 30% of the card accounts in an issuer's portfolio change or close every year. If you bill saved cards, close to a third of your card book can go stale inside twelve months, and each stale card shows up as a failed renewal that looks exactly like a customer who stopped paying.

Account updaters are the scheme-run services that catch that drift: Visa Account Updater (VAU), Mastercard Automatic Billing Updater (ABU), Amex Cardrefresher and Discover's Network Account Updater. The pages that rank for them explain the concept and stop. None covers the parts that bite in production: Visa's 180-day minimum inquiry cycle, Mastercard's API returning CONTACT for an account that is closed, the letter V meaning different things in Visa's issuer and acquirer files, or why your PSP skips the updater entirely when a network token is on the charge. Scheme rules and PSP field names below were checked against primary documentation on 22 October 2026.

What Is a Card Account Updater?

An account updater is a database the card scheme keeps of changes issuers make to cards: a new card number after a reissue, a new expiry date, a closed account, or an instruction to go back to the cardholder. Issuers write to it. Merchants, through their acquirer or PSP, read from it for the cards they hold on file.

The issuer side is tightly ruled. Visa's Core Rules (Table 8-3, April 2026 edition) say a PAN or expiry update must be submitted "within 2 business days of Account Number activation", and only once an authorisation on the new number can be approved. Closed-account advice is allowed only where the closure is permanent. A closed response is the issuer telling you the relationship is over, not that the card is temporarily blocked.

The merchant side is narrower than most teams assume. Visa lets acquirers inquire only "for accounts where the merchant has an ongoing customer relationship and the customer has authorized COF payments". The updater is for stored credentials, not for cleaning a list of cards you once saw. It is also not a validity check. A "no match" tells you the issuer had nothing to report, not that the card will approve.

How Visa Account Updater Works: Batch, API, Real Time and Push

Visa runs four channels into the same data, and which one your PSP uses changes what you see.

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

Stripe Connect vs Adyen for Platforms: Who Pays?

Tom Wang — Wed, 21 Oct 2026 07:26:27 +0000

On a Stripe destination charge, a chargeback is debited from the platform's balance, even when the seller shipped the goods and the platform never touched them. On a direct charge, the same chargeback lands on the seller. One parameter decides who eats the loss, and most marketplace teams choose it in their first week, from a docs page that recommends it for unrelated reasons.

The pages that rank for "Stripe Connect vs Adyen" compare pricing and review scores. None puts Stripe's charge types next to Adyen's splits and Mangopay's wallets at API level, and none asks the UK question underneath: if your platform collects money for sellers, is that a regulated payment service? Field names below were checked against the docs on 21 October 2026.

Stripe Connect vs Adyen for Platforms vs Mangopay: The Short Version

All three let a platform take a buyer's payment, keep a commission and pay the seller without the platform holding client money in its own bank account.

	Stripe Connect	Adyen for Platforms	Mangopay
Seller's funds sit in	A connected account balance	A balance account per account holder	An e-money wallet per user
Platform takes its cut with	`application_fee_amount` or `transfer_data[amount]`	A split with type `Commission`	`Fees` on a wallet-to-wallet transfer
One payment, several sellers	Separate charges and transfers	Several `BalanceAccount` splits	One transfer per seller wallet
Losses by default	Depend on charge type and `controller.losses.payments`	The platform's liable balance account	Not stated; your fee is reversed on chargeback
Documented cap on holding seller funds (UK)	90 days on manual payouts	20 business days of `settlementDelayDays`	None; payouts gated by KYC level

Stripe makes you choose a charge type, Adyen wants a split instruction, and Mangopay hands you wallets. Each moves liability somewhere specific.

Does a Marketplace Need FCA Authorisation in the UK?

The law shapes the architecture. The Payment Services Regulations 2017 exclude payments made through a commercial agent (Schedule 1, Part 2, paragraph 2(b)), but only an agent authorised by agreement to negotiate or conclude the sale "on behalf of either the payer or the payee but not both".

The FCA reads that narrowly. PERG 15.5 Q33A describes the platform that acts for both sides: it takes the buyer's money into an account it controls, that payment does not settle the buyer's debt to the seller, and the platform then pays the seller under its own agreement with the seller. The authority must be real, meaning the ability to bind the principal; supplying the technical means for placing orders does not count. Escrow-style platforms are flagged as likely to need authorisation.

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

EIP-3009 vs EIP-2612 vs Permit2: Gasless USDC

Tom Wang — Tue, 20 Oct 2026 09:30:22 +0000

A USDC authorisation signed with the EIP-712 values your code uses on Base Sepolia will fail on Base mainnet. The domain name is "USDC" on the testnet and "USD Coin" on mainnet, so the signature recovers to a different address and the contract reverts. Nothing in the user's wallet shows the difference.

Three standards let someone move stablecoins by signing a message instead of paying gas: EIP-3009, EIP-2612 and Uniswap's Permit2. The pages that rank for them explain one at a time. None puts the three side by side on nonces, token coverage and gas, and none covers the per-chain domain values that break real integrations. This guide does, using the specs, the token source code and on-chain reads I ran on 20 October 2026.

What Is EIP-3009 Transfer With Authorization?

EIP-3009 lets a token holder sign a transfer that anyone else can submit and pay gas for. The signed message is the transfer itself:

TransferWithAuthorization(
  address from, address to, uint256 value,
  uint256 validAfter, uint256 validBefore, bytes32 nonce
)

A relayer calls transferWithAuthorization(from, to, value, validAfter, validBefore, nonce, v, r, s). The token checks the signature, checks the time window and moves the funds in one call. No allowance is created and nothing is left behind for a spender to reuse.

Three details matter in practice:

Nonces are random 32-byte values, not a counter. The spec's rationale is that sequential nonces force ordering: if a relayer submits nonce 5 before 4, it fails and wastes gas. With random nonces a payer can have many authorisations outstanding at once, and each settles independently.
The time window is strict on both ends. Circle's implementation requires now > validAfter and now < validBefore.
authorizationState(authorizer, nonce) returns whether a nonce has been used, and each use emits AuthorizationUsed(address indexed authorizer, bytes32 indexed nonce). cancelAuthorization is listed as optional.

EIP-3009 was created in September 2020 and is still a Draft. It sat as Stagnant until October 2025, when it was moved back to Draft. That revision also added a line saying the standard "does not apply to smart contract accounts". Hold that thought, because USDC disagrees.

How Does EIP-2612 permit Work?

EIP-2612 is older (April 2020) and Final. The holder signs an approval, not a transfer:

Permit(address owner, address spender, uint256 value, uint256 nonce, uint256 deadline)

Someone calls permit(...) to set the allowance, and then the spender calls transferFrom. That is two state changes, usually in one transaction from a contract that wraps both. Nonces are sequential per owner (nonces(owner)), and the deadline is inclusive: the permit is valid while block.timestamp <= deadline.

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

Amex Intent Intelligence: Consent Agents Can Carry

Tom Wang — Thu, 15 Oct 2026 07:15:35 +0000

American Express has published the thing EMVCo only described. On 13 October 2026 it released Intent Intelligence, a framework that turns a shopper's instructions to an AI agent into a record with its own identifier, a signed token and a lifecycle the issuer can check at authorisation and again in a dispute.

The timing is pointed. EMVCo's Board of Advisors met in Hanoi on 13 and 14 October to decide what happens to its draft agentic payments framework, and as of today no readout has been published. Amex, one of EMVCo's six owners, shipped its own answer on the first morning of the meeting.

What Is Amex Intent Intelligence?

Amex calls it "a suite of services to create, update, and cancel a user's authenticated intent". It is delivered through the Agentic Commerce Experiences (ACE) Developer Kit, the SDK Amex launched in April alongside Agent Purchase Protection, and the press release describes it as a core ACE service.

The flow has four steps:

The agent collects what the customer wants and submits it through the Create Intent API.
The customer authenticates and signs off, by passkey or through a sign-off the issuer has delegated to the agent or a wallet.
Two artefacts come back: an Intent ID, which Amex describes as the primary key for every later request against that intent, and a Proof of Intent Token, which is a JSON Web Token carrying the high-level constraints.
The token is exchanged for a scoped payment credential. The agent pays with that credential at checkout and never sees the card number.

Issuers can run risk checks and step-up after sign-off, before anything is bought. The intent then feeds authorisation and fraud decisions, and Amex says issuers can evaluate disputes against the cardholder-confirmed version.

Hannah Bozian, Amex's VP of agentic partnerships, told Digital Transactions the network already sees "thousands" of agentic transactions a week across the integrations it supports. That is a small number for Amex, and an honest one.

What Fields Does an Amex Intent Contain?

The technical post by Inderpreet Hundal and Gianna Rotondo lists eight fields. This is the part a press release would never print, and it is where the design decisions show.

Field	What it holds
Purchase Summary	What was agreed, with personal details irrelevant to the purchase removed
Max Amount	The most the customer will pay
Intent Expiry	Last date the intent can be actioned; the token expires then too
Merchant Data	Only if the customer named a merchant
Item-Level Conditions	Dependencies between items; absent means each item is fulfilled independently
Maximum Number of Transactions	Expected number of purchases, mapped to the number of credentials that can be issued
Order Context	Typed `Intent` (preferences) or `Cart` (approved products), each item and merchant with a reference ID
Purchase Criteria	Conditions that must hold before the agent buys, such as a restock or a date

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

Interchange++ vs Blended Pricing: A UK Guide

Tom Wang — Sat, 10 Oct 2026 07:18:12 +0000

A UK consumer debit card payment carries 0.2% interchange. A French-issued debit card paying the same UK merchant online carries 1.15%. On blended pricing you never see that difference, because your provider averages it into one rate. On interchange++ you see it on every line, sometimes two months after the payment.

That is the real choice between the two models. The question is less "which is cheaper" and more "who carries the variance, and can your systems handle the data". The pages that rank for this query explain the definitions well and stop there. None of them shows what the fee data looks like when it arrives, which is the part I end up debugging. This guide covers both.

What Is Interchange++ Pricing?

Interchange++ (IC++, interchange plus plus) splits the cost of a card payment into three parts and passes each through separately:

Component	Who sets it	Who keeps it	Typical UK range
Interchange	The card scheme (Visa, Mastercard), within regulatory caps	The issuing bank	0.2% to 1.5%+, depending on card and region
Scheme fees	The card scheme	Visa or Mastercard	Not published as a simple rate; dozens of line items
Acquirer markup	Your PSP or acquirer	Your PSP	Negotiated, plus a fixed per-transaction fee

The first "plus" is scheme fees. The second is the acquirer's margin. The acquirer only negotiates the last one. Interchange and scheme fees are passed through at cost, whatever they turn out to be.

Interchange depends on the card: consumer or commercial, debit or credit, premium or standard, domestic or cross-border, card present or not, and whether the transaction qualified for a lower tier (tokenised, authenticated, enhanced data). I covered one of those levers, the token discount, in the network tokenisation guide.

Interchange++ vs Blended Pricing: What's the Difference?

Blended pricing (Adyen calls it "blended rates", Stripe calls it standard pricing) charges one rate per card category and absorbs the underlying costs. Stripe's UK list price, checked on 10 October 2026:

Card type	Stripe UK standard pricing
Standard UK cards	1.5% + 20p
Premium UK cards	2.8% + 20p
EEA cards	2.5% + 20p
International cards	3.15% + 20p
Currency conversion	+2%

Stripe offers IC+ only on custom pricing, "for businesses with large payments volume or unique business models". Adyen goes the other way. Its UK price list is IC++ by default for cards: £0.11 per transaction plus interchange, scheme fees and a 0.60% markup on Visa and Mastercard.

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