Smart Commerce Layer: research into safer AI-assisted payment journeys

Short answer

The DIGITAL EUR Smart Commerce Layer is an independent research prototype, not a payment product. It asks whether an AI shopping assistant can prepare a euro checkout while a deterministic policy engine, never the AI, checks payee, amount, item, currency and expiry, and every step is recorded in a privacy-minimised, hash-chained log a merchant can reconcile. No real money moves.

The sections above show the simulation, the four hypotheses and the milestone table. This section documents the research design behind them: the problem, how it relates to existing work, what the event envelope actually contains, the threats we test against, how we plan to measure results, and where the approach stops. Status as of 5 November 2026: research only, synthetic data only, no ECB affiliation, and no application to any ECB programme is claimed here.

What research problem does the Smart Commerce Layer study?

AI assistants are starting to take part in buying decisions. Card networks, payment providers and protocol groups are building ways for software agents to pay on a person's behalf. The hard part is not moving the money; licensed providers already do that well. The hard part is consent: showing, after the fact, that what was paid for is what the person actually agreed to, and doing so without collecting more personal data than the purchase needs.

Our research question is narrow:

Can a human-controlled flow, in which an AI only proposes and a deterministic rule set decides, produce evidence that a consumer, a merchant and a bookkeeper can each rely on, with fewer avoidable errors and less personal data than a baseline chat-to-checkout flow?

Three practical problems sit underneath that question:

1. Drift between intent and execution. A person asks for one paperback from one bookshop for up to €24.90. An assistant that "helpfully" picks a hardcover edition, a lookalike seller or a higher price has changed the deal. The person may only notice when the statement arrives.
2. Evidence that cannot be reconciled. Merchants reconcile payments against invoices. If the agent's reasoning, the approval and the receipt sit in different systems with different identifiers, a human ends up matching them by hand. This is the same problem our existing euro reconciliation demo addresses for ordinary bank transfers.
3. Over-collection. The easiest way to make a dispute provable is to log everything: names, emails, account numbers, the full chat. That is the opposite of data minimisation, and it creates a store of personal data that has to be protected for years.

This is human-in-the-loop payment automation research in a specific sense. The human is not asked to approve every step; the human approves a mandate once, and a rule set enforces it. A person comes back into the loop only when the rules say so: when evidence is missing, when a dispute is opened, or when a bookkeeping match needs confirming.

How does this relate to existing work?

We ran a prior-art review before writing this page. The honest conclusion is that the Smart Commerce Layer is not a novel payment technology. Spending mandates for agents, consent tokens, conditional release of funds, electronic receipts and capture-after-delivery all exist already, in production or in published specifications. The table summarises what we found and checked on 5 November 2026.

We also searched for "Quaestrum", which appears in our internal competitor list. We could not find a public page for it on 5 November 2026, so we make no claim about it.

What, if anything, is different here?

Not the parts. Possibly the combination, and that is what we want to test rather than assert:

• Evidence for bookkeeping, not only for authorisation. Most agent-payment work stops at "was this payment authorised?". Our log continues to delivery evidence, human review and an invoice-match suggestion, because a micro-merchant's real cost is often the reconciliation afterwards.
• Explicit, enumerable rejection reasons. Each refusal carries a fixed reason code with a plain-language explanation. That makes refusals countable in an evaluation and explainable to the consumer.
• Privacy budget per party. We try to measure, field by field, what each party receives, rather than describing a design as "privacy-preserving" in general terms.
• Rail independence. Nothing in the envelope depends on cards, SEPA transfers or a future digital euro. Any adapter to a real rail is future work that would require a licensed partner.

If a reviewer shows that this combination is already published, we will say so on this page and narrow our claims. The ECB innovation opportunities explained page covers the official programme separately; the two pages are deliberately distinct.

What does the event envelope contain?

Every step in the simulation is written as one event. The fields below are exactly those defined in the prototype's TypeScript code (LogEvent in the research module); nothing is added for presentation.

The eight event types follow the journey in order: INTENT_CAPTURED, CONSUMER_APPROVAL, CHECKOUT_PROPOSED, POLICY_DECISION, SYNTHETIC_RECEIPT, then either DELIVERY_EVIDENCE or DISPUTE_HUMAN_REVIEW, and finally INVOICE_MATCH. A rejected proposal stops after POLICY_DECISION; no receipt is created.

Which rules does the policy engine apply?

The policy engine is a pure function: the same mandate, approval and proposal always give the same decision. It returns APPROVED only if no rule fires, with the single reason WITHIN_MANDATE. Otherwise it returns REJECTED with every reason that applies.

What does the hash chain prove, and what does it not?

Each event's hash covers its own content and the previous event's hash, using JSON with sorted keys so that property order cannot change the result. A verifier walks the chain and reports the first event whose sequence number, link or content does not match. The prototype's automated tests check that altering any single event, dropping the first event or swapping two events is detected.

What the chain does not prove: it is not signed, so anyone able to rewrite the entire log can produce a new, internally consistent chain. Tamper-evidence therefore depends on the final hash being stored somewhere the writer cannot change, such as a copy held by the consumer or the merchant. Signatures and external anchoring are open research items, not features.

A worked example from the simulation

The baseline scenario uses a clearly fictional bookshop. The consumer approves one item, "Paperback: Example Field Guide", from merchant-example-books-001, up to 2,490 cents (€24.90), valid until 12:00 UTC.

1. The AI proposes the same item and merchant at €24.90. No rule fires: APPROVED, a receipt is issued, carrier evidence arrives, and the invoice for €24.90 produces MATCH_SUGGESTED. A person still confirms the match in bookkeeping.
2. The AI proposes €34.90 instead. AMOUNT_ABOVE_MANDATE fires: REJECTED, no receipt, nothing proceeds.
3. The AI proposes €19.90 for the same item. This is approved, because a lower price is still within consent. Whether that is always right is itself a research question: a much lower price can signal a different edition or a counterfeit listing, which the item rule only partly catches.
4. Delivery evidence never arrives. The chain records DISPUTE_HUMAN_REVIEW, and the invoice match is HELD until a person resolves it.

Which threats does the design address?

We model the AI assistant as untrusted but not malicious by default: it can make mistakes, be manipulated by a web page (prompt injection) or be optimised for something other than the consumer's interest. The policy engine never reads the AI's reasoning; it compares structured fields only. That is deliberate, because text that persuades a model cannot persuade a string comparison.

Cybersecurity, fraud prevention and key management are outside what this prototype can demonstrate. The ECB's 2026 call also lists those topics as outside the scope of its AI exploration work, which is one reason we treat them as open problems rather than claims.

How will the research be evaluated?

None of the hypotheses has been tested yet. The protocol below is what we intend to run, written before any data is collected so that the metrics cannot be chosen after seeing results.

Baseline and treatment

• Baseline: a chat-to-checkout flow in which the assistant produces a payment link and the merchant later reconciles a CSV bank export against invoices, as in our reconciliation lab.
• Treatment: the consent-to-receipt flow, with a mandate, deterministic policy decision, minimised receipt and hash-chained log feeding the same reconciliation step.

Both run on synthetic merchants, items and prices. No real payment accounts are used.

Protocol

1. Define a fixed scenario set: valid purchases plus deliberate deviations (payee, amount, item, currency, expiry, missing delivery, dispute), with the expected decision written down for each.
2. Run every scenario through both flows and record each event.
3. For the user study (H4), show participants the approval screen and the rejection explanation, then ask what they approved and why a proposal was refused.
4. Compute the metrics below per scenario and in aggregate.
5. Publish the scenario set, the expected outcomes and the raw counts, including scenarios where the treatment performs worse.

Metrics

Small samples and synthetic tasks limit what any result can show. We will report confidence ranges, not headline percentages, and we will not publish numbers until the study has run.

How does the design minimise personal data?

The prototype separates a consumer profile (synthetic name, email and account identifier) from everything that is logged. The profile is an input to the simulation but is never written to an event or a receipt. The mandate is referenced by a pseudonymous identifier that is not derived from the name or email.

This follows the EU data protection principles of data minimisation and data protection by design (Articles 5 and 25 of the General Data Protection Regulation). It also mirrors the ECB's stated aim, in its 2026 call, of evaluating e-receipt approaches in line with privacy by design. The table also shows the weak points: item text and delivery references can reveal more than intended, and reducing them is part of H2. For the separate question of how the digital euro itself would handle privacy, see our digital euro privacy guide.

What is the regulatory context?

This is general information, not legal advice; the author is not a lawyer.

• Strong customer authentication (PSD2). Under PSD2 and its technical standards (Commission Delegated Regulation (EU) 2018/389, Article 5), remote payments need "dynamic linking": the payer is shown the amount and the payee, the authentication code is specific to both, and any change to either invalidates it. Our policy rules on payee and amount follow the same logic one step earlier, at the consent stage. They do not replace authentication by a licensed payment provider.
• Payment Services Regulation (PSR) and PSD3. The Council and Parliament reached a provisional agreement on 27 November 2025 covering fraud prevention, payee verification and liability. At the time of our check we could not confirm publication in the Official Journal, so we treat its detailed provisions as not yet applicable.
• AI Act human oversight. Article 14 requires high-risk AI systems to be designed so that people can understand, monitor, override and stop them, and to counter automation bias. After the 2026 "AI Omnibus" amendment, these obligations apply to Annex III systems from 2 December 2027. A shopping assistant does not appear to be an Annex III category on our reading, so we use Article 14 as a design reference, not as a legal requirement we claim to meet. The transparency duty to tell people they are interacting with an AI system (Article 50) applies more broadly.
• Licensing. The prototype does not hold, transfer or initiate payments, so it is not a payment service. Any connection to a real payment rail would have to run through a licensed provider.
• Digital euro. The digital euro has not been issued and its legislation is still being negotiated. A digital euro adapter appears in the milestones only as dependent on official standards and access. For what the proposal could mean commercially, see digital euro implications for merchants.

What are the limitations?

• Synthetic only. Every merchant, item, price and timestamp is invented. Results from synthetic tasks may not transfer to real shopping.
• Rules, not judgement. A deterministic engine can only enforce what the mandate expresses. Mandates that are too narrow cause false rejections; mandates that are too broad permit unwanted purchases.
• No replay protection yet, no signatures and no external anchoring of the hash chain.
• String identifiers. Payee and item checks compare text. Real deployments need verified merchant identities and product identifiers.
• One currency, one item, one merchant. Baskets, split payments, refunds and subscriptions are not modelled.
• No independent review yet. The design has not been audited by a payment provider, security researcher or data protection specialist.
• Small team, no partners. The project is run by the operator of this site, a small Bulgarian company, and has no payment, merchant or research partner at the time of writing.

How can you cooperate on this research?

We are interested in hearing from:

• Licensed payment service providers with a test environment, to evaluate whether the envelope can carry real authorisation and capture evidence;
• Merchants and bookkeepers willing to describe how they reconcile agent-assisted or link-based payments today;
• Researchers in human-computer interaction, security or data protection who could review the evaluation protocol or co-design the user study;
• Consumer organisations interested in how approval screens are understood.

A privacy-reviewed contact form is planned. Until it is available, the operator's details are on the imprint. We will not list partner names or logos unless a partner has agreed in writing, and cooperation does not imply any relationship with the ECB or the Eurosystem. How we handle corrections is described in our editorial policy.

Frequently asked questions

Is the Smart Commerce Layer a digital euro product?

No. It is an independent research prototype that runs on synthetic data in the browser. The digital euro has not been issued, and nothing here connects to ECB or Eurosystem systems.

Can the AI assistant spend money on its own?

No. In the design, the AI can only propose a checkout. A deterministic policy compares the proposal with the consumer's mandate, and any proposal in which the AI claims to approve itself is refused. In the current prototype no money moves at all.

Has this been submitted to or selected by the ECB?

This page claims no submission, selection or endorsement. Some themes overlap with the ECB's published focus areas, such as e-receipts, conditional payments and AI in payments, but that reflects shared interest, not an official relationship.

Why not let the AI decide when a small change is reasonable?

Because a probabilistic model can be wrong or manipulated, and a payment decision needs to be repeatable and explainable. The IMF note on agentic payments makes a similar argument for keeping authorisation deterministic. If a change is reasonable, the consumer can approve a new mandate.

What happens if the parcel never arrives?

The log records that delivery evidence is missing, the case goes to a person, and the invoice match is held. Nothing is settled automatically.

How is this different from Mastercard Agent Pay or AP2?

Those are payment-network and protocol initiatives that move or authorise real payments. Our prototype moves nothing; it studies the consent and evidence trail around a purchase and how that trail feeds bookkeeping. AP2's signed mandates are more advanced than our unsigned log.

Will the results be published?

Yes, including results that do not support the hypotheses. Scenario sets, expected outcomes and metrics will be published once the evaluation has run; there are no results yet.

Sources

• ECB, Digital euro innovation platform (accessed 5 November 2026)
• ECB, "ECB presents findings from digital euro innovation platform and announces second round of experimentation", 26 September 2025 (accessed 5 November 2026)
• ECB, Call for expressions of interest in a new wave of digital euro innovation platform activities, 28 September 2026 (accessed 5 November 2026)
• ECB, Digital euro innovation call document, 28 September 2026 (PDF) (accessed 5 November 2026)
• Agent Payments Protocol (AP2), official site (accessed 5 November 2026)
• Mastercard, "Mastercard unveils Agent Pay, pioneering agentic payments technology to power commerce in the age of AI", 29 April 2025 (accessed 5 November 2026)
• Sardis, package listing on PyPI (accessed 5 November 2026)
• Alchemy, "Introducing AgentPay: one integration for every agentic payment protocol", April 2026 (accessed 5 November 2026)
• Adyen documentation, Capture (accessed 5 November 2026)
• IMF, Sonja Davidovic and Hervé Tourpe, "How Agentic AI Will Reshape Payments", IMF Note 2026/004, April 2026 (accessed 5 November 2026)
• Commission Delegated Regulation (EU) 2018/389, Article 5 (dynamic linking), consolidated text (accessed 5 November 2026)
• Council of the EU, "Payment services: Council and Parliament agree to step up the fight against fraud and increase transparency", 27 November 2025 (accessed 5 November 2026)
• AI Act, Article 14: Human oversight (unofficial consolidated reading) (accessed 5 November 2026)
• Future of Privacy Forum, "The AI Act Implementation Timeline: What Changes Under the AI Omnibus?" (accessed 5 November 2026)
• Regulation (EU) 2016/679 (General Data Protection Regulation) (accessed 5 November 2026)