On 13 October, the BIS published Project Aurum Phase 2. Its exploratory digital-cash prototype combines privacy-enhancing technologies with compliance capabilities. The report explicitly says it is not a production-ready technology stack and discusses trade-offs in performance, complexity and recovery. This is research, not a retail currency launch.
Event / source publication date: 13 October 2026The following is Human Fintech’s analysis
Ask for the data map.
A payment involves several parties, but they do not necessarily have the same information needs. A merchant wants evidence that an order has been paid. A customer wants a receipt. An infrastructure operator has a different job again. Treating every participant as a reason to circulate the complete record makes the privacy discussion less precise. The analysis below is our interpretation, not a description of additional Aurum features.
For readers assessing a payment service, a useful starting point is a map of those roles. Who receives which fields, for what purpose and for how long? What information travels with a payment, and what stays with the institution that collected it? These questions turn a broad assurance into something that can be examined against the service’s actual documentation.
The exception can define the experience.
Consider a hypothetical customer who loses a phone while travelling. A frictionless purchase the previous day says little about the help available now. Can the customer establish ownership, and what evidence is necessary? Which organisation handles the request? Does the recovery process expose information that ordinary payments kept separate? A good explanation should cover this path as clearly as the checkout screen.
Disputes create another test. A customer may need to demonstrate a particular transaction without volunteering an unrelated spending history. That is a practical design question for support teams as well as engineers. It also helps readers understand why privacy cannot be evaluated solely by whether a name appears on one screen. The surrounding processes matter.
Separate the demonstration from the commitment.
An experiment is useful because it expands the set of questions that designers can ask. A live service carries further obligations: people must know how it behaves, where to seek help and what its limits are. Readers should therefore resist treating the existence of an experimental feature as evidence that their own wallet already offers it.
For a product team, the next conversation should bring together engineering, operations and customer support. Walk through a routine payment, a lost device and a contested purchase using the same proposed data policy. Look for points where the explanation changes or responsibility becomes unclear. For users, the equivalent test is to ask for a plain-language account of those situations. Trust becomes easier to assess when the boundaries are visible before money is committed.
White Fintech.
Part VII of White Fintech covers payment businesses, including company structure, risks, compliance and economics. Explore the contents and the free sample.
Complete English edition, PDF + EPUB. Read the first 30 pages free, with no sign-up.