Master Data, Privacy & Security

On a Tuesday morning an email arrives in the accounts payable team of a valve manufacturer. A supplier of seals writes that its wallet address has changed and asks for the next invoice to be paid to the new address. Had it reported a new IBAN, there would be a routine for this: a call-back on the known number, approval by a second person. Since October 2025 the bank has also checked, before every credit transfer, whether the payee's name matches the IBAN. For an address on a blockchain this second check does not exist. Whether the new address belongs to the supplier is for the company to establish itself, and what it records in doing so is master data.

An address names no holder

An IBAN belongs to an account, and behind the account stands a bank that knows its customer. An address on Ethereum, by contrast, is derived from a key that anyone can generate without asking anyone. It carries no name and no country. That a particular address belongs to the seal supplier is therefore recorded in exactly one place: the supplier's master record. That entry is the real control point. If it is right, reconciliation, sanctions screening and approval run on the right basis; if it is wrong, all three work carefully on the wrong payee.

An address can also belong to many. When a customer pays through a trading platform, the platform's address appears as the sender, as described in Reconciliation & Payment Flows. Anyone who stores it in that customer's master record will then also assign that customer the payments of every other customer on the platform. An address therefore belongs in a master record only when it is established that it is attributable to that business partner alone.

Proving your own wallet

The first proof is not one the company demands but one it has to provide. The valve manufacturer transfers tokens from its account with a crypto-asset service provider to a wallet it runs itself. Under Regulation (EU) 2023/1113, that wallet's address is a self-hosted address. If the amount exceeds 1,000 euros, the provider must assess under Art. 14(5) whether the address is owned or controlled by its customer. The same applies to incoming transfers under Art. 16(2). What else the rules require is described in Cross-Cutting: Compliance & Reporting.

The Travel Rule guidelines of the European Banking Authority (EBA), in force since 30 December 2024, set out how the proof is provided. The provider should use at least one of several methods. The finance team can meet two of them itself: sending a small amount set by the provider between the address and its provider account, or signing a specified message with the address's key. Once the provider is satisfied, it records this in its systems and need not repeat the check for later transfers to the same address. The guidelines call this whitelisting.

In-house it pays to record this proof on the wallet's master record: when it was provided, to which provider and who signed. Otherwise, once the provider or the person responsible changes, it can no longer be traced on what basis the address counts as the company's own. One implementation is HashBuch by Setrion GmbH, which also operates this knowledge hub. There a customer can only assign a wallet itself after signing a message under the EIP-4361 standard with the wallet's key.

Checking other parties' addresses

For a supplier's address nobody takes this work off the company's hands. The EBA's methods can be carried over, but with one limitation. If someone signs a specified message or sends a specified small amount from the new address, that proves control of the address. It does not prove who controls it. If a fraudster wrote the email, they pass both tests with ease.

Only a second channel establishes the link to the supplier. That is the call on the number in the master record, not the one in the email, to a person purchasing knows. In this order the two tests complement each other. The call establishes that the supplier wants the change, and the signature that it actually controls the address given. Only then is the address released.

Setting up an address also includes sanctions screening, and not just once. The US authority OFAC, for example, lists addresses in its sanctions list. An address that was unremarkable when it was set up may later appear on such a list. Whom the obligations behind this fall on is described in the cross-cutting article.

Who may change addresses

The German principles for the proper keeping and retention of books in electronic form (GoBD) require an internal control system. As examples, paragraph 100 names access authorisations and segregation of duties. For addresses this means in practice: whoever creates or changes an address does not approve payments to it. The whitelist against which payments run is described in Custody & Safekeeping. It is fed from the verified master record.

Paragraph 111 goes a step further. When master data changes, the unambiguous meaning in the transaction data must be preserved; if necessary, master data must be historised with validity dates. The change history itself must not be alterable afterwards either. For the seal supplier this means: the old address is not overwritten but ends on a date. All earlier payments on the blockchain still carry the old address. Without the time-limited entry, none of them could be assigned to the supplier any more, and last year's reconciliation would become wrong after the fact.

For the finance director the risk lies less in the technology than in a missing control. A payment to a wrong address can generally not be recovered, and no bank stops it on the way. The controls that have grown up over years for bank details have to be set up specifically for addresses: second channel, segregation of duties, time-limited master records. Their cost arises once when they are set up and then with every new address.

What of this is personal data

If the supplier is a limited company, its address is data about a company. The case is different for a sole trader, such as a commercial agent who invoices in stablecoins. Under Art. 4(1) of the General Data Protection Regulation (GDPR), data is personal if a natural person can be identified through an identifier. The European Data Protection Board (EDPB) applies this expressly to addresses in its blockchain guidelines, adopted on 7 July 2026. They may constitute personal data when they enable direct or indirect identification of a natural person. The agent's master record contains exactly this link.

A clear separation follows. The blockchain carries the address, the ERP system the name, and the link between the two stays in the ERP system. The EDPB advises against storing personal data on the blockchain and states that it should not be stored in the content of transactions. That also applies to references of the kind described in Reconciliation & Payment Flows for matching payments. A reference may point to the invoice, but not to the person.

If the agent asks for their data to be erased after the business relationship ends, Art. 17 GDPR meets two limits. The first is intended: under Art. 17(3)(b) the right to erasure does not apply where the law requires the processing, for example to retain accounting records. The second lies in the technology. The agent's payments remain visible on the blockchain, whatever the company deletes. Only the address stands there, however. Once the link in the ERP system has been deleted after the retention periods, at least the connection the company made is gone. How retention periods and erasure fit together in the individual case is for the company to settle with its data protection officer.

Your own address is public

According to ethereum.org, Ethereum is a public and transparent ledger by design. For the company's own receiving address this has a consequence that does not arise with an IBAN. If the same address appears on every invoice of the valve manufacturer, any customer can look it up in a block explorer. There they see all receipts: from which addresses, when and how much, plus the balance. A customer who is also a competitor can read along with the sales.

A separate receiving address for each customer helps. It keeps the payment flows apart and, as a side effect, makes reconciliation easier, because the address itself names the customer. It comes at a price, however. Every address is another master record that has to be created, proven to the provider, historised and retained. The balance is also spread across many addresses, which treasury has to consolidate if it wants to deploy the money as a whole.

Who already knows the holder

For credit transfers, verification of payee has existed since 9 October 2025. Art. 5c of the SEPA Regulation, inserted by Regulation (EU) 2024/886, requires the payer's bank to match the payee's name against the IBAN before approval. For this, the payee's bank checks on request whether the two match. That is possible because it knows its customer. For a self-hosted address there is no such party. Knowledge of who owns an address has so far arisen with a verified basis in only one place. That is the provider that had it proven under the Travel Rule and placed it on its whitelist. A payee check for addresses would find its starting point there.