Amazon vs. Muse is the open finance v screen-scraping fight, round two

On September 20, Amazon began blocking Meta's Muse, a personal AI agent that shops and checks out on a customer's behalf, from accessing Amazon.com. Amazon's stated reasons were specific: Meta never asked permission for Muse to access Amazon's store, the agent doesn't identify itself while it browses, and it appears to capture and store customer credentials. Shopify took the opposite position within a day, opening its merchants' stores to the same agent through its own checkout flow.

Read past the AI framing and this is a fight open finance has already had, as Simon Taylor pointed out the day the story broke, in his Fintech Brainfood newsletter.

The same shape as the screen-scraping years

Before open banking had accredited, authenticated APIs, it had screen scraping: services logging into a customer's bank portal with that customer's own credentials, unannounced, unauthenticated, and indistinguishable from the customer themselves as far as the bank could tell. Banks objected on security grounds. Regulators eventually pushed the market toward a different model, one where a third party accessing an account has to be an accredited, identifiable participant, operating within a defined scope, rather than a piece of software quietly wearing someone else's login.

Muse holding a customer's stored Amazon credentials without announcing itself is the same pattern in a different storefront. An agent showing up at a merchant's digital front door, unidentified, acting with a customer's own access, is exactly the arrangement open finance spent years replacing with something accountable. Amazon's specific complaints, no permission, no disclosure, no visibility into who or what is actually behind the login, are the same complaints banks made about screen scrapers a decade ago.

The two questions this always comes down to

Payments opinion former Dave Birch has argued that agents force questions a traditional transaction never had to answer: what is this agent, a genuine service or a tampered-with copy, and what is it allowed to do, and on whose behalf. That's authorization and scope, and it's exactly what open finance's own third-party accreditation and consumer consent model was built to answer: who this participant is, and what it's actually been authorized to access. Agentic commerce didn't invent this problem. It's asking open finance's question about a new kind of intermediary.

There's a third question sitting just behind those two, one Amazon's complaint makes concrete: if the agent gets it wrong, stores a credential badly, acts outside what it was actually asked to do, who is answerable for that? Open finance ran into the same question, and mostly hasn't answered it. Accreditation and consent tell you who's allowed in. They don't, on their own, tell you whether that participant's risk is still what it was on day one, or who's on the hook when it isn't.

Why the fix won't be one central list

Birch's own view is that nobody is going to build a single global database of every agent, its code, and its permissions, because the market will end up more distributed than that. Open finance has already run into a version of this: a single central registry can work well enough in a smaller market, but strains as a network grows large and the entities in it change faster than a static list can be updated. What tends to hold up at scale is continuous, distributed risk monitoring, verifying participants on an ongoing basis, across a network, rather than checking a list once and assuming it still holds.

Google and Shopify's answer so far, the Universal Commerce Protocol, is aimed at exactly this: an interoperability standard meant to vet agents, confirm intent, and let merchants and agents authenticate each other rather than negotiate access one exclusion notice at a time. Whether that specific standard wins isn't the interesting question. The interesting question is that the industry keeps arriving, independently, at the same need open finance already ran into: accredit the participant, monitor its risk continuously, and know where liability sits before something goes wrong rather than after. Open finance built the first part. The other two are still mostly unbuilt.

Invela is the infrastructure layer that makes open finance trustworthy - accrediting who's in the network, monitoring risk in real time, and ensuring liability lands in the right place.

‍