Article 16(2) sets out the legal bases on which an authority may ask you for real beneficiary data. Article 16(1) adds the one that catches people out: where the basis is the real beneficiary's own written approval, that approval must be attached. Source: Cabinet Resolution 109/2023, Arts. 16(1) and 16(2).

In the same UAE UBO Register app, open Authority Requests and record who asked and the legal basis. The basis field offers four options and they mirror Article 16(2) exactly. The user guide does not print the four labels, so read them on your own screen rather than trusting a summary — including this one.

Creating the request record takes its own snapshot. That is the design point of the whole screen. What you disclosed stays reconstructible after the register moves on, so "what did we hand over, and when" is a question with a documented answer rather than an email search.

Disclose against the recorded basis, and no further. These are dates and places of birth, home addresses and passport numbers. Record the requester, record the basis, attach what the basis requires, and hand over what was asked for. A generous interpretation of a narrow request is not helpfulness; it is an unlogged disclosure of somebody's passport number.

Worked example. On 5 October 2026 an authority asks Al Mirfa Contracting LLC for its real beneficiary data, on the basis of the written approval of one named beneficiary. The team records the requester, selects that basis, and attaches the signed approval as required by Article 16(1). Creating the record takes snapshot four. Six weeks later the Rahmani holding is restructured and the register changes — and the October disclosure is still readable exactly as it stood, because it was frozen when it was made.

The failure mode. An approval-based request logged with no attachment. Nothing external stops you, and the record looks complete on screen; but the one document Article 16(1) requires is the one that is not there, and you will discover this at the worst possible time.