Privacy Policy

PRIVACY POLICY

UORA — uora.ae

Operated by P L M Portal L.L.C.

Version: 2.0

Effective date: 28 September 2026

Last updated: 28 September 2026

This version supersedes version 1.0 of 17 September 2026, except for the part of version 1.0 that is in force — see clause 29.8. It is published at https://uora.ae/privacy and it is the privacy notice that applies to this platform.

One section below is in force and binding: SMS, at version 1.0. It covers every text message UORA sends or receives — what is collected, what it is used for, how long it is kept, and how to stop the messages.

Sections 1 to 29 are the privacy notice that applies to this platform, published under Federal Decree-Law No. 45 of 2021. Where they and the section below both speak to text messages, the section below is the one that governs, because it is version-pinned inside the platform and cannot move without a new version number.

S.1 Who is sending. Text messages are sent by UORA, the online review-dispute arbitration platform operated by P L M Portal L.L.C., Dubai, United Arab Emirates (trade licence no. 1473120). PLM is the controller of the personal data described in this section.

S.2 What we collect for SMS. Your telephone number in international format; the text of each message sent to you and of any reply you send; the time each message was sent and the time any reply arrived; the delivery status the carrier reports and any error code it returns; the identifier the messaging provider assigns to the message; and, where a message carries a link, whether and when that link was opened. Where a message carries a one-time code we store a hash of the code, when it was issued, when it expires and how many times it was tried — never the code itself in readable form after it has been sent.

S.3 What we use it for. Three things and nothing else. To serve the documents the UORA Rules require to be served on a party to an arbitration. To send a one-time code so that a party can open their own case file and no one else can. And to keep the record of service — what was sent, to which number, when, and whether it arrived — because that record is evidence a court may examine when an award is put forward for ratification. Our lawful basis is the performance of the arbitration agreement between the parties and our legitimate interest in keeping an accurate record of it.

S.4 We do not sell or share it. We do not sell or share your SMS opt-in data or personal information with third parties for marketing purposes. UORA sends no marketing messages of any kind. Your telephone number is disclosed only to the messaging provider that carries the message on our behalf, and to the other party and the arbitrator in the case itself, where the Rules require the record of service to be produced.

S.5 How long we keep it. Message records form part of the case file and are kept for as long as the case file is kept. A record of service cannot be deleted while it may still be needed to prove that a notice was served.

S.6 Stopping messages. Reply STOP to any message and we stop texting you. We keep a record that you did so, so that you are not texted again by accident; that record is not published. Stopping text messages does not end an arbitration or stop a period running — see the SMS Terms on the Terms of Service page.

S.7 Your rights. You may ask what we hold about you, ask for it to be corrected, and complain about how it is handled. Write to support@uora.ae.

1.1 This policy explains what personal data P L M Portal L.L.C. ("PLM", "we", "us") collects when it operates the UORA platform at uora.ae, why we hold it, who we share it with, where it is processed, how long we keep it, and what rights you have.

1.2 It is written under UAE Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data (the "PDPL"). It is published in English. The PDPL does not require a privacy notice to be given in Arabic, and Articles 25 and 26 of Federal Law No. 15 of 2020 on Consumer Protection, which do require Arabic, reach the terms of contract, payment and warranty rather than this notice. The instruments that a party is served with in a case — a Cure Notice, a Request for Arbitration, a Certificate of Service, an Award — are issued in Arabic and English together, and the Terms of Use are published in both.

1.3 We have tried to write it in short sentences. Some of what it describes is unusual, and we have chosen to describe it plainly rather than in general terms. In particular:

(a) A person may receive a formal notice from UORA without ever having visited this website, created an account, or agreed to anything with us, and that notice is produced and sent by machine with no person reading the file first. Clause 3 is written for that person.

(b) Some of the personal data we hold cannot presently be deleted, even on request. Clause 15 explains exactly which data, why, and what we are doing about it.

(c) Some records we produce contain personal data that people are often surprised by, including the address and device that the signer of a document signed from, which is printed inside the document. Clause 8.9 says so.

(d) Some of our own automatic erasure and retention rules do not yet exist, or exist and have never run. Clause 20 says which, rather than describing a programme we do not operate.

(e) Some controls that earlier versions of this policy described do not exist, and where we have found that out we have said so in the clause itself rather than quietly dropping the sentence. Clauses 24.4 and 27.2(b) are the two that matter most.

1.4 Where this policy describes something we intend to do but have not yet done, it says so in those words. Where a rule does not exist, it says that too. We would rather publish a gap than publish a control we do not have.

1.5 The PDPL Executive Regulations. Article 28 of the PDPL required the Council of Ministers to issue Executive Regulations. On our information they have not been issued. Secondary commentary conflicts on whether they have since been issued, and we could not verify an issuance against a primary source: the UAE Legislation portal’s entry for the PDPL lists no related legislation. We therefore write this policy as though they are not in force, and we will correct this clause if that turns out to be wrong. That has three consequences for what this policy can promise, and we state them at the front because they run through the whole document: no adequacy decision has been made in respect of any country, so every transfer outside the UAE rests on Article 23 and none rests on Article 22 (clause 18); no standard contractual clauses exist to adopt, so each transfer contract has to be written specially (clause 18.2); and no response period and no breach-notification deadline are prescribed, so the periods in clauses 21.4, 24.1 and 28.1 are our own undertaking and not a statutory minimum.

1.6 If you think any statement in this policy is wrong, tell us. Clause 28 says how, and clause 28.1 covers that as well as a complaint about how we handled your data.

2.1 The Controller of the personal data described in this policy is:

P L M Portal L.L.C.

Trade licence number 1473120, issued by the Department of Economy and Tourism, Dubai

The Metropolis Tower, Office 1305

Marasi Drive, Business Bay

Dubai, United Arab Emirates

2.2 UORA is a product operated by PLM. It is an online platform through which disputes about public reviews are handled under the Rules, where the parties have adopted the UORA arbitration clause in their own contract.

2.3 PLM is licensed on the Dubai mainland. It is not established in a free zone with its own data-protection legislation, so the PDPL applies to it in full and neither the Dubai International Financial Centre nor Abu Dhabi Global Market data-protection regimes apply. Nothing in this policy should be read against those regimes; in particular, the breach-notification deadline that applies in one of them does not apply to us.

2.4 PLM is not a law firm, not an arbitration institution, and not a provider of legal or dispute-resolution services. PLM does not decide disputes. Arbitrators listed on the UORA Roster act independently and are not employed, instructed or paid by PLM. This matters for privacy because it tells you who is answerable for what: PLM decides how the platform processes data; the Arbitrator decides the dispute and is answerable for what they do with the case material they receive.

2.5 Privacy contact. Write to us at:

Email: support@uora.ae

Post: Data Protection, P L M Portal L.L.C., The Metropolis Tower, Office 1305, Marasi Drive, Business Bay, Dubai, UAE

Email is the route we ask you to use for a request under clause 21. We also accept a request by post, and we will acknowledge a postal request in the same way.

2.6 Data Protection Officer. We have not appointed a Data Protection Officer. The Personal Data Protection Law requires one only in the cases set out in Article 10, and on our assessment none of them applies to us at our present scale; we will appoint one and say so here if that changes. Data protection matters are handled by the contact in clause 2.5, at support@uora.ae.

2.7 Making a request costs you nothing. We do not charge for anything in clause 21 or clause 28.

3.1 This clause is for you if a business has started a procedure under the Rules about a public review, and you have received a Cure Notice, a Request for Arbitration or any other document from UORA. In this policy you are the Respondent — the party a case is brought against. This clause is also the information the PDPL requires us to give you before we start processing your data, which we could not give you beforehand because we did not know you existed until the claim was filed; clauses 3.13 to 3.15 are that information.

3.2 You did not give us your data. The party claiming against you gave it to us. It gave us your name, the contact details it holds for you under your contract with it, the text of the review it says you published, and any documents it says are relevant. It may also have given us a copy of your identity document. We do not require one.

3.3 You did not agree to anything with us. There is no account. There is no registration. There is nothing on this website that you have accepted. Whatever obligation you are under runs from the contract between you and that party, which it says contains a clause adopting the Rules. It does not run from anything between you and PLM.

3.4 No person read your file before the notice was sent. When the claiming party paid the Stage 1 fee, the Cure Notice was generated and served automatically, within seconds. No administrator reviewed the claim first, and the check that your contract incorporates the Rules rests on the claiming party's own declaration alone. That is what Section 5.2 of the Rules provides, and it is how the platform is configured.

3.5 We did not check the other party's account of the facts, and we treat what it tells us about you as an assertion rather than as an established fact. The claiming party confirmed to us, in a signed declaration, that its contract with you contains that clause and that its account of the review is accurate. We acted on that confirmation. If you tell us something is wrong, clause 21.6 says what we will do.

3.6 Because the notice went out without a person reading it, you have a right to require a person to look at it. Clause 22.4 explains that right, how to use it, and the one limit on what a person can then do. It is a right the PDPL gives you and that nothing in the Rules or in the other party's contract can take away.

3.7 If you say there is no contract, or no such clause, that is not merely part of the dispute — it goes to whether we may hold your data at all. Clause 21.6(d) says what happens.

3.8 You have the rights in clause 21, and you do not need an account to use them. Clause 21.6 covers correction. Clause 21.7 covers erasure and its limits. Two of those rights are narrower for you than you might expect, and we say so rather than leave you to discover it: the right to have your data sent to someone else in a machine-readable form is available under the PDPL only where processing rests on your consent or on a contract you are party to, and neither is true of you, so we offer it as a courtesy and not as a right (clause 21.5(e)); and the right to object to processing is available under the PDPL only in three defined situations, which do not include objecting to an arbitration (clause 21.8).

3.9 Your access to the case is by a link and a one-time code sent to a contact detail already on the file. We will never ask you on that page for a password, and we will never ask you to type card details into a page of ours. There is one payment you may choose to make — the Settlement Sum in clause 3.11 — and it is taken on our payment provider's own page and never on uora.ae itself. So if a message or a page asks you for a password, or asks you to enter card details on uora.ae, it is not us. The wording on the case page itself is presently wider than this clause, because it says we will never ask you for a payment on that page, and the settlement route does. We are correcting the page, not this clause. If a notice reached a contact detail that is not yours, or that other people can reach, tell us at once — see clause 21.11.

3.10 Time, and how to ask for more of it. The notice you received states a deadline, and it is short — often 48 hours. It runs from the moment the message was transmitted to a contact detail in your contract, not from the moment you read it, and it is not extended because the last day falls on a weekend or a public holiday. Clause 14.5 explains that, and it also records that we have not settled whether the Arbitration Law permits us to count the period that way. A deadline can be extended, but only by us or by the Arbitrator: there is no control on your case page that asks for more time, and clause 22.5 says so. If you need more time, write to us at the address in clause 2.5 or say so on your case page, and we will put it in front of the person who can decide it. Ask early. Asking concedes nothing.

3.11 Money. Nothing is charged to you in the ordinary course of the procedure: the claiming party pays the fees. There is one exception, and it is your choice, not ours. If the Rules version in your contract is 1.7 or later, you may end the dispute by declaring that the review has been removed and paying a Settlement Sum under Section 13A of the Rules. That sum is AED 3,300, of which AED 1,000 is a processing fee payable to PLM and not refundable in any circumstance, and AED 2,300 is collected by us and held for the claiming side. Clause 9 says what we then hold about you.

3.12 If your identity document is filed in the case, it goes into the bundle that is filed at court if the case reaches that point. Clause 16.4 says so. So does the full number on it, and the photograph: we mask identity numbers in our own party records, but we do not alter the document itself, because it is an exhibit.

3.13 Why we hold your data. To run the procedure the Rules set out: to produce and serve the notices, to record when and how they were served, to put the parties' submissions before an Arbitrator, to issue an award, and to support an application to the Dubai courts to ratify and enforce that award. We also hold it to keep the platform secure, to keep our accounting records, and to answer a request or a complaint. Clause 13 sets out each purpose and the provision of the PDPL we rely on for it.

3.14 Who else sees it, inside and outside the UAE. Inside the UAE: the claiming party, the Arbitrator appointed to your case, any party to whom the claim is assigned (named in clause 16.3), our administrators, and the Dubai courts if a court application is made. Outside the UAE, because of how messages and the website work: the company that carries our email, which is the channel through which the documents themselves are sent; Meta, where a document is delivered to you by WhatsApp; the company that hosts our website and carries your browser's traffic; our payment provider if you pay a Settlement Sum; our error-monitoring provider; a translation service, if an Arbitrator uses it as a drafting aid; our accounting provider; the operator's own mobile telephone, where an alert about a payment is sent (clause 16.9); and, if an award is not complied with and the claiming party takes the step, the review platform the review is published on. Clause 17 names each one and says what it receives, and clause 18 says what we rely on for each transfer.

3.15 How your data is protected when it leaves the UAE. Article 23 of the PDPL allows a transfer outside the UAE in defined cases, including where it is necessary to establish or exercise rights before judicial entities. No country has been declared adequate by the UAE authority, so we do not rely on adequacy for any transfer. Clause 18 states, transfer by transfer, what we rely on. For three transfers we have not settled which case in Article 23 applies: the traffic between your browser and our service, the email carrier that carries the served documents themselves, and the sending of an award to a review platform. Clause 18 leaves those lines blank rather than filling them in, and we would rather show you the blank.

3.16 Silence is not an admission. Not answering does not concede anything, and it does not remove any right you have. It does mean the procedure continues, because the timetable comes from the contract, not from us.

3.17 Where you find this policy. Its address is printed on every document we serve on you, in English and Arabic, and it is linked from your case page.

In this policy:

"Arbitrator" means a member of the UORA Roster appointed to decide a Case.

"Assignee" means the person to whom a Claimant may assign its claim under Section 9 of the Rules. The Assignee is a person designated by PLM in its platform settings, not chosen by the Claimant from the market. Clause 16.3 names the Assignee and says what that means for your data.

"Bureau" means the UAE Data Office established under Federal Decree-Law No. 44 of 2021, which the PDPL calls the Office and which supervises compliance with the PDPL. We use "Bureau" throughout.

"Case" means a matter opened on the platform under the Rules.

"Claimant" means the party that opens a Case. A Claimant may be a company or an individual, and may be either the provider of goods or services or the customer, because the Rules bind both alike.

"Controller" means the person who decides why and how personal data is processed, and who is answerable for it under the PDPL. For everything described in this policy, that is PLM, except where clause 16 says otherwise.

"Journal" means the append-only record described in clause 15.

"Notice" means a document served under the Rules, including a Cure Notice, a Request for Arbitration, Procedural Order No. 1 and an Award.

"Personal Data" has the meaning given in the PDPL. The PDPL defines Personal Data to include Sensitive Personal Data and Biometric Data, so where this policy says Personal Data it covers those too. We use the capitalised term throughout; where the phrase appears in lower case it carries the same meaning.

"Processing" has the meaning given in the PDPL. It includes collecting, storing, using, disclosing and deleting.

"Respondent" means the party a Case is brought against, and who published the public review that is the subject of the Case. A Respondent may be a company or an individual.

"Rules" means the UORA Review Dispute Resolution Rules, in the version incorporated into the parties' own contract. The version the platform issues to a new Case is version 1.7, issued 19 September 2026. That value has to be read from the running service: our own configuration files are snapshots rather than the thing that governs, and the version matters to a reader because the settlement route in clause 3.11 exists only from version 1.7. Later versions are published and earlier versions remain in force for the Cases whose contracts named them; each published version is immutable.

"Service Provider" means a company we instruct to carry out processing on our behalf. Clause 17 names them all and states, for each, what it receives and where it processes. Most act only on our instructions under a written contract. Two do not, and clause 17.1 says which in the entry itself rather than generally.

"Settlement Sum" means the amount a Respondent may pay under Section 13A of the Rules to end a dispute, described in clause 3.11.

"Track B" means a claim in which the Claimant says specific statements in the review are false and identifies the passages and its reasons.

"delegated person" means the limited role the Rules give PLM: receiving submissions, issuing and serving the standard-form Cure Notice on behalf of the Claimant, maintaining the Service Log, issuing certificates of service, and designating the Arbitrator from the Roster. PLM does not decide any dispute.

5.1 From you directly. If you create an account, file a claim, act as an Arbitrator, answer a notice, upload a file, make a payment, or write to us, we receive what you provide.

5.2 From someone who enters your address on our sign-in page. Our sign-in page accepts an email address from anyone, with no verification. If a stranger enters your address, we create an inactive account record and send one message to that address. The record grants nothing. It is deleted after 30 days, but only where it was never verified, never signed in to, never given a password and never touched by us, and where nothing else has attached to it — clause 20.8(b) states the conditions in full, and they are narrower than "never used". Outside them the record is kept, and you may ask us at any time to remove it. We limit how often a message can be sent to the same address.

5.3 From a Claimant, about a Respondent. This is the route that matters most, and it is unusual. When a Claimant opens a Case, it gives us Personal Data about the Respondent, who has not given it to us and has not been asked. Specifically:

(a) the Respondent's name;

(b) the Respondent's email address, mobile number and WhatsApp number, as stated in the parties' contract or given for communications under it;

(c) the Respondent's postal address, emirate and nationality, where the Claimant holds them — and on nationality see clause 12.4, because we have no statutory necessity for it;

(d) the type and number of the Respondent's identity document, and in some cases a scanned copy of it — see clauses 7.3, 7.4 and 5.6;

(e) the text of the public review, its web address, the platform it appears on and its reference;

(f) on a Track B claim, the passages the Claimant says are false, and why;

(g) the contract between them, and any other evidence.

5.4 We tell the Respondent, on the case page and on the notice, that this is where the information came from and that we have not verified it.

5.5 A Claimant is answerable for the data it gives us. It has its own obligations under the PDPL in respect of its customer's data. Clause 25 sets out what we ask of it, and what presently enforces it.

5.6 We do not require a Respondent's identity document, and we do not ask for one. Where a Claimant files one as evidence, we hold it as part of the case file, and it may go into a court bundle (clause 16.4).

5.7 From public sources. The text of the review is Personal Data that the Respondent made public themselves, on a public review platform. We hold the Claimant's copy of it, and a dated snapshot of it captured by the Claimant. The connection between a review published under a display name and a named, contactable individual is not public. It is an assertion by the Claimant drawn from its own records, and we do not treat it as public data — see clause 13.6.

6.1 Account records. For account holders (Claimants, Arbitrators, finance users and administrators — never Respondents): name, email address, telephone number, language preference, whether the email and phone have been verified, whether the account is active, the date of last sign-in, the roles held, how the account was created and by whom, and the dates of any deactivation with the reason and who did it.

6.2 Passwords. Where a password is set, we store a one-way cryptographic hash of it and the date it was set. We never store the password itself. We also count failed attempts against an account.

6.3 Email address history. When an account holder changes their email address, we keep the previous address, when it was verified, when it was replaced, by whom, and why. We keep it unmasked. Its purpose is to explain sign-in and account correspondence. It is not the record of service of notices: service is recorded separately, on the case record described in clause 7.2, and changing an account address does not redirect anything on a live case. Nothing deletes this record. It is removed only if the account record itself is deleted, which for a verified account does not happen — see clauses 20.9(d) and 20.8(h).

6.4 Organisation records. For a Claimant: legal name, trade name, trade licence number and issuing authority, tax registration number, address, emirate, contact email and phone, the name and title of the authorised signatory, and our internal verification status and notes. Those notes are Personal Data about the people named in them, are limited to what is needed to record a verification decision, and are included in an access request under clause 21.5.

6.5 Where the Claimant is an individual rather than a company, that same record holds a natural person's legal name, identity document type, masked identity document number, the last four digits of it, and nationality. That matters later: clause 20.7(b) explains that those details survive an erasure on a retained tax record.

6.6 Organisation documents. We hold the trade licence and the identity document of the authorised signatory — typically an Emirates ID or passport scan — with the file name, size, type, a digest of the file, and who uploaded it. This record is held against the organisation, not against a Case, so that a later Case does not have to ask for it again. Three consequences follow, and a Claimant should tell the individual concerned: it is included in the court bundle of any Case that party brings where the Case file holds no copy of its own (clause 16.4); erasing a Case does not remove it; and no retention rule reaches it at all, so it is held indefinitely (clause 20.9(a)).

6.7 Bank accounts held as a preference. Where a Claimant, or an individual, records a payout account so that it does not have to be given again, we hold the account holder name, the bank name, the IBAN and the SWIFT or BIC code. We hold these in ordinary readable form and not encrypted. This record is separate from the copy held on a Case (clause 9.4): erasing a Case clears the Case's copy and leaves this one, there is no route in the product by which you can delete it, and no retention rule reaches it. Clause 20.9(c) says so.

6.8 Invitations to join an account. Where an account holder invites a colleague to join their organisation's account, we hold the email address the invitation was sent to, the role offered, a digest of the invitation link, its expiry date, and who invited, accepted or revoked it. We hold the address in ordinary readable form, because the invitation has to be matched to whoever accepts it. We hold it whether or not the invitation is ever accepted, so a person who never chose to deal with us and never replied is nonetheless recorded here. Nothing deletes it: it goes only if the organisation record itself goes, and clause 20.8(h) explains that in practice an organisation record is kept. Clause 20.9(f) says so.

7.1 For each party to a Case (Claimant, Respondent and Assignee) we hold: full name, legal name, identity document type, a masked identity document number and its last four digits, a reference to any identity document filed, email address, mobile number, WhatsApp number, postal address, emirate, nationality, signatory name and title, and language preference.

7.2 These records are versioned, not overwritten. If a contact detail is corrected during a Case, we mark the old record as superseded and add a new one. We do not delete the old one, because a notice served on an address that was later corrected has to remain explainable years afterwards, including to a court.

7.3 Identity document numbers on this record are masked on entry. We store the last four digits and a masked form. There is no column on this record that holds the full number.

7.4 Masking the number does not mask the document. Where an identity document is filed as evidence, we hold the document as it was given to us. The full number on its face, the photograph and everything else printed on it are in that file, and the file goes into a court bundle if the Case reaches that point (clause 16.4). So the accurate statement is not that we hold only the last four digits of your identity number: it is that our own party record holds only the last four digits, and the document itself is kept whole because it is an exhibit.

7.5 A working copy of the claim form. While a Claimant completes a claim, the platform saves the form as it is typed, so that nothing is lost. That saved copy is retained on the Case record until the claim is filed, when it is cleared. Where a Claimant entered a Respondent's identity document number, one of the two routes by which that form reaches us removes the number before it is written and the other does not, so the unmasked number can still be written to that copy. A nightly job empties it from an unfiled claim seven days after the last change. Until both routes strip it, we will clear the working copy of any Case on request, and we clear it when a Case is erased.

7.6 An unfiled claim is not reached by any retention rule. A claim that is started and abandoned is never closed, and both of our automatic case rules run from closure. So everything the Claimant typed about you before the Case existed — name, address, review text and the rest — is held until somebody erases it by hand. Clause 20.4 says so, and you may ask us at any time to erase an unfiled claim about you.

8.1 Case content. The web address of the review, the text of the review, its reference and the platform it appears on; the title and reference of the parties' contract; a Track B statement and the passages alleged to be false with the reasons given; and, after an award, any court case number, ratification date and execution case number.

8.2 Evidence files. Files uploaded by either party: contracts, the page of the contract carrying the clause, review screenshots, review status screenshots, identity documents, trade licences, proof of cure, proof of compliance, defence and reply attachments, and other material. For each we hold the file itself, the file name as uploaded, its type and size, a digest of the original bytes, the party and person who uploaded it, its exhibit label, the capture time read from the file where the file carries one, and whether the Arbitrator relied on it.

8.3 File names. We keep the name of every uploaded file exactly as your own computer supplied it. File names frequently contain a person's name. That name is printed on the List of Exhibits, which is part of a court bundle, and it is written into the Journal described in clause 15, from which it cannot presently be removed. If you would rather a name not travel that far, rename the file before you upload it.

8.4 Photographs, and the information hidden inside them. A photograph taken on a phone usually carries hidden information — the time it was taken, and often the location and the device. We extract the capture time first and store it, because when a screenshot was taken is often the fact in dispute. We then create a second, display-only copy with the hidden information stripped, and it is that stripped copy the other party sees on screen. The original file, with the hidden information intact, is the exhibit: it is what is digitally fingerprinted and what goes into a court bundle. So the honest statement is that the hidden information is removed from the copy the other party sees and kept in the copy filed with the court.

8.5 We do not presently warn you about this at the point of upload. We say it here, and we intend to say it at the upload control as well. Until we do, this clause is the only place it is said.

8.6 Documents we issue. Every document we produce is stored in English and Arabic, as a web page and as a PDF, with a document number, a digital fingerprint of each, a verification code, and a second structured copy of everything printed on it — every name, address, identity number, passage of the review, figure and date, and for a signed document an embedded copy of the signature image itself. We keep that second copy so the document can be reproduced and re-verified years later, unchanged. That second copy is the widest single collection of Personal Data on the platform, and clause 20.7(b) explains the one place it survives an erasure.

8.7 Submissions. Every filing by a party: its text, any structured content, the files attached, a digest of it, who filed it, and the network address and browser identification string it was filed from.

8.8 Inbound messages. If you reply to a UORA notice by WhatsApp, we record your message text (up to 4,000 characters) and your telephone number, and it is filed as a submission in your Case and is visible to the Arbitrator. The automatic reply that number sends says that messages sent to it are not read. That reply is wrong, we are correcting it, and this clause states what actually happens. If you reply by email, we record the message text and the technical headers, including sender address, subject, authentication results and the sending server's address.

8.9 Service records. For every attempt to serve a document we record: the party, the channel (email, WhatsApp, SMS where used, or the case page), the destination address or telephone number in full, the provider used, the provider's message identifier, the status, the time, any error, whether it was service or a courtesy copy, and the provider's own webhook payload including the full text of the message sent. We record when a served document was first opened on the case page, and how many times a short link in a message was opened and when it was last opened. These records are evidence: they are what a certificate of service and a Service Log recite. The Service Log prints the destination on its face and is a required exhibit in a court bundle, so your email address or telephone number goes into the court file.

8.10 Signatures, and what is printed on a signed document. When a person signs a document on UORA we record the method, the typed name or the drawn signature image, the time, the fingerprint of the document at signing, and the network address and browser identification string of the signer. The network address and the browser identification string are also printed on the certification page inside the signed PDF, in English and Arabic. That PDF is served on the other party and goes into a court bundle. Because the Arbitrator signs the award, this means an Arbitrator's own network address is printed on every award they issue. We intend to remove both from what is printed and to keep them only in our internal record. We have not done so.

8.11 Award records. The Arbitrator's findings and operative order, and any private working draft. A draft is visible only to the Arbitrator who wrote it, is served on nobody, and has no effect until an award issues.

8.12 Objection and appointment records. Who was designated, who designated them, the conflict answers and disclosures given, any conflict override and its reason, any objection and its reasons, and how it was resolved.

8.13 Compliance records. Whether the Respondent claimed compliance and when, the proof filed, and the Claimant's verification of it.

8.14 Settlement records. Where a Respondent settles under Section 13A of the Rules: the declaration made, its full text, the time, the network address and the browser identification string it was made from, the payment, and the Claimant's confirmation or objection.

8.15 Consent records. For each declaration or consent: who made it, in what role, the subject, the version of the wording, a digest of the exact wording shown, the time, the network address, and the browser identification string.

9.1 Payments. For each fee: the payer, the amount, VAT and total, the currency, the method, the payment provider's payment and session identifiers, the status, the dates paid or refunded, any amount withdrawn under a card dispute, the invoice number and series, the tax state recorded at issue, free-text notes, and who recorded a manual payment. Where the payer is an individual, the payment record is Personal Data about that person and we treat it as such.

9.2 Cash, and who may pay in it. A stage fee may be discharged in cash only by a person we have individually permitted to do so. We record that permission against that person's own account, together with which administrator gave it, and why, in at least a sentence. Where cash that was recorded as due never arrives, we record that the fee was written off and the reason, which is a note about the person who owed it. Those records sit on the account and are kept for as long as the account is — clause 20.8(h).

9.3 We never see or hold card data. Card number, expiry, security code, cardholder name and billing address are entered on the payment provider's own page, which is theirs and not ours. There is no field for any of them anywhere in the platform and nothing in the platform reads them back. Because that page is the provider's, the provider also receives your network address and device directly from your browser.

9.4 The assignor's bank account. If a Claimant elects to assign its claim, we require its payout account before the fee is taken: account holder name, bank name and IBAN. It is held on the Case record, and it is printed into the Recovery Sharing Agreement, the instrument that says who gets what out of any recovery. A separate copy may be held as a preference under clause 6.7.

9.5 That agreement is never served on anyone, ever. The Respondent cannot see it. The Arbitrator cannot see it. It is not in any court bundle. Four separate mechanisms in the platform keep it out. The bank details are also stripped out of our application logs, and stripped out of the Journal before anything is written to it.

9.6 The account details are visible to the Claimant whose account it is, to the Assignee as the other party to that agreement, and to our administrators. Clause 23.9 states the position on internal access.

9.7 Money we hold for someone else. Where a Respondent pays a Settlement Sum, the part of it collected for the claiming side is money we hold rather than money we have earned. We record who it is owed to, the amount, the bank account it is to be paid to, and the date and reference of the transfer when it is made. The transfer is made by hand by our finance desk; nothing in the platform moves money automatically.

10.1 Display name, biography in English and Arabic, the email address for documents, an image of the handwritten signature, whether the Roster entry is active, and whether it is published.

10.2 Nationality and address. These are held because Article 41(5) of Federal Law No. 6 of 2018 requires an award to state the names, nationalities and addresses of the arbitrators. The platform will not issue an award without them. An Arbitrator should understand what that means in practice: the address, which is often a home or chambers address, is printed on every award they sign, disclosed to both parties and filed with the court.

10.3 What is published, and what else is disclosed. On the public Roster we publish only the display name and the two biographies. Contact details, nationality, address and the signature image are never published there, and the query that builds the public Roster is written so that it cannot disclose them. Separately, the name of the Arbitrator appointed to a Case is disclosed by the verification page for documents issued by the tribunal — see clause 19.3. That disclosure does not depend on whether the Arbitrator is listed on the public Roster.

10.4 An Arbitrator's records are not reached by any retention rule, and the instruments issued about them — a Deed of Nomination, for example — are not reached by Case erasure, because they belong to a person rather than to a Case. Clause 20.9(e) says so.

11.1 Sessions. For each sign-in: the account, the Case and party role for a Respondent session, a device identifier where the browser supplied one, a session identifier, the times issued, expiring and revoked, the network address, and the browser identification string.

11.2 Sign-in credentials. Sign-in links and one-time codes are stored as one-way digests, never in readable form. The destination a code was sent to — an email address or a telephone number — is stored in readable form, so that the code can be checked against it. Where a sign-in link is used to change an email address, the new address is also held in readable form. Clause 20.8(c) says how long those records are kept, and the answer is not a period.

11.3 Failed password attempts. We store a keyed digest of the address a password was tried against, not the address itself, together with a count. These rows are deleted automatically 24 hours after the last attempt.

11.4 Case access tokens. The link in a served notice contains a token that identifies the Case. It is stored as a digest and lasts 90 days. A fresh one is issued with each document served on a Respondent, so a served document never carries an address that expires before the period it opens. A token can be revoked — see clause 21.11. That token is the whole of a Respondent's access control, so treat the link as you would a password.

11.5 Short links. The short link used in a message, the address it points to, the Case, how many times it has been opened and when it was last opened.

11.6 Application logs and telemetry. We keep operational logs of requests, errors and system events. These carry case identifiers, user identifiers, request identifiers, component names and statuses. Before anything is written to a log, an automatic filter removes credentials, tokens, bank details, session identifiers, the secret parts of respondent and short-link web addresses, Emirates ID numbers in both written forms, UAE PASS identifiers, and UAE mobile numbers, and masks email addresses.

11.7 The limits of that filter, stated honestly. It masks an email address but keeps the domain, because an operator diagnosing a failed delivery needs the domain. Its telephone-number patterns cover UAE numbers; a foreign mobile number may pass through unmasked. It does not remove personal names, foreign identity numbers or postal addresses; those reach logs only where our own code puts them there, which it does in a small number of places. A small number of internal job records are written without passing through the filter at all. So a statement that our telemetry carries nothing that identifies a party would be too broad, and we do not make it.

11.8 Where the telemetry goes. Our monitoring workspace is shared with other products of the same group, so the set of people who can read UORA's operational records is wider than the set who can read a case file, and wider than UORA. Clause 17.1(e) names the provider.

11.9 Clause generation. If you generate a UORA arbitration clause while signed in, we record the provider name, the clause text in both languages, the Rules version, the amounts chosen, and the account that generated it. No retention rule reaches this record — clause 20.9(b).

11.10 Clients section consent. If your company is listed in the Clients section, we record the company name, a normalised key for it, the sector, your organisation, the consent time, the network address you consented from, the version of the terms shown to you, and the account that asked. We record it as pending. Nothing appears publicly until an administrator approves it. Five things about that consent are less than they should be, and we set out all five rather than earlier versions of this policy admitted:

(a) there is no separate request. The platform infers that you want to be listed from your having chosen a sector while generating a clause;

(b) there is no way to decline. The sector control offers only real sectors and no empty option, so once the control has loaded a value is always set and the request is always inferred;

(c) the box you tick reads only that you agree to the Terms and Conditions. It does not mention listing. The longer sentence our own interface publishes as the consent wording — which does mention listing — is not the sentence the page shows you;

(d) we record the version number of the wording but not a digest of the wording itself, so what a listed company agreed to is answerable only by reference to that version number, and we hold two different sentences against the same number;

(e) we no longer tell you, at the time, that a listing request has been made.

Clause 13.11 says what follows for the legal basis. No retention rule reaches the record.

11.11 Public-site measurement. For the public information pages we record that a page was opened, which control was pressed, the shape of the address, the referring site's name, and a device class. We store no network address and no browser identification string at all on those records. Clause 27 describes it in full. That statement is about these records and not about the download records in clause 11.14.

11.12 Enforcement records. Where a Claimant or Assignee proceeds to court, we record the milestones an administrator enters: what happened, when, any amount, the court or execution reference, and a note.

11.13 Requests you make to us. When you exercise a right under clause 21, we record your name, the address you wrote from, a note identifying the matter, which right you asked for, the dates we received, acknowledged and answered it, how we verified who you are, and the outcome. That register is itself Personal Data about you. Clause 20.8(k) says how long we keep it.

11.14 Downloads of published documents. When a published document such as the Rules is downloaded from our site, we record which document was taken, which version of it, the coarse place the download was started from, the instant, and the daily value described in clause 27.2(a). Where you were signed in at the time, we also record your account and your organisation, so for a signed-in reader this record identifies you and says which version of the Rules you read and when. No retention rule reaches it, nothing prunes it, and erasing a Case does not touch it — clause 20.9(g). Our export tool does not see it either — clause 21.5(b).

12.1 We do not ask for, we do not require, and we take the steps we can to keep out, data revealing racial or ethnic origin, political or philosophical opinions, religious beliefs, health, biometric or genetic data, criminal record, or data concerning a person's sex life.

12.2 Three routes by which such data nonetheless reaches us:

(a) A review, or a party's account of the underlying transaction, may say something about a person's health, beliefs or personal circumstances. A review of a restaurant, a clinic, a pharmacy or a hotel can easily do so, and where the reviewer is the Respondent that is sensitive data about the very person who never agreed to deal with us. We do not filter reviews by subject matter, and the Claimant chooses what to file.

(b) An identity document may show a photograph or place of birth. We run no facial recognition and no other technology of that kind over it, so on our understanding the photograph is not Biometric Data within the PDPL, which defines that term by reference to processing using a specific technology that allows unique identification.

(c) An Arbitrator's Statement of Independence. Article 10 of Federal Law No. 6 of 2018 requires a person notified of a possible appointment as an arbitrator to declare, in writing, all circumstances likely to give rise to doubts as to their impartiality or independence. That is the declaration the Article requires, and it is not a declaration about a criminal record. Separately, the same Article makes a sentence for a felony or misdemeanour involving moral turpitude or dishonesty a disqualification from acting as an arbitrator, so we ask an Arbitrator to confirm the absence of one, because we have to satisfy ourselves of eligibility before designating them. That confirmation is ours to ask for rather than something the Article requires to be declared, and it is rendered into a document and served on both parties. Earlier versions of this policy attributed the criminal-record declaration to the Article itself.

12.3 A notice or a submission may allege criminal conduct by a party, and the Cure Notice reserves the claiming party's right to complain to the authorities. That is an allegation, not a record of a conviction. We treat it with the same care as sensitive data as a precaution, without asserting that it is criminal-record data within the PDPL.

12.4 Nationality. We hold an Arbitrator's nationality deliberately, and Article 41(5) of Federal Law No. 6 of 2018 is why: an award must state the names, nationalities and addresses of the arbitrators. We also hold a nationality field on a party record and on an individual Claimant's record. Article 41(5) does not require a party's nationality. It requires the names and addresses of the litigants, and the nationalities only of the arbitrators. Earlier versions of this policy cited Article 41(5) as the necessity for a party's nationality, and that was wrong. So the position we can defend is narrower: we hold the field because a Claimant may supply it, we do not use it to infer racial or ethnic origin, we do not process it for any other purpose, and no provision of law requires it of a party. Whether the field is removed is a decision for us rather than for the law, and it has not been taken.

12.5 What we do with the content in 12.2(a) and (b). We do not select it, analyse it, index it or reuse it. We hold it, we reproduce it in the documents the procedure requires, and we pass it to the Arbitrator and, on a court application, to the court, because it is part of the material in dispute.

12.6 The basis on which we hold it. The PDPL defines Personal Data to include Sensitive Personal Data, and the provision that governs lawfulness — Article 4 — makes no separate rule for it. So we rely on the same Article 4 case for sensitive data as for the rest of the case file, stated at clause 13.2, and we do not claim a further condition that the PDPL as enacted does not require. What sensitive data does change is what we owe elsewhere: it raises the standard of security we must apply under Article 20, it is one of the triggers for the impact assessment described in clause 23.14, and it bears on whether we must appoint a Data Protection Officer under Article 10. This statement is about the PDPL as enacted; the Executive Regulations are permitted to add controls, and if they do we will change it.

12.7 We do not profile, score, rank or rate any person, and no part of the platform assesses anyone's character, credibility or risk. That is worth saying in this clause because the profiling-based triggers in Articles 10 and 21 of the PDPL turn on it.

13.1 How the PDPL works, so that this clause reads correctly. Article 4 prohibits processing without the data subject's consent and then excludes eleven cases from that prohibition. It is not a menu of equal bases: consent is the rule, and we have to show that a case applies. So for each purpose below we name the case by its number. The PDPL has no general legitimate-interests basis, and we do not rely on one anywhere. Where an instrument of ours has said otherwise, clause 29.8 withdraws it.

13.2 Running the procedure, and serving notices. This is the core purpose. We use party names, contact details, the contract, the review and the evidence to produce notices and orders, serve them, record service, put submissions before the Arbitrator, issue an award, and support ratification and enforcement.

Legal basis: Article 4(3) — processing necessary to initiate any procedures of a legal claim or the defence of rights, or related to judicial procedures. This is the primary basis for all Case processing, it is the basis on which we process Respondent data, and it is the only basis we rely on for it.

Earlier versions of this policy added Article 4(10) in support — processing necessary to fulfil obligations imposed on us by other laws of the State — on the footing that service implements Article 24 of the Arbitration Law, that an award must carry the particulars required by Article 41(5), and that a ratification petition under Article 55 requires the record. We have withdrawn that, for three reasons. Article 41(5) binds the arbitral tribunal, and clause 2.4 says we are not the tribunal and do not decide. Article 55 binds the person seeking enforcement, who is the Claimant or the Assignee and not us; clause 16.4 says we do not file. And clause 14.5 records that we calculate periods in derogation from Article 24 rather than in compliance with it, so it would be odd to call the same provision an obligation imposed on us. Article 4(3) carries this processing without help, and a wrongly claimed Article 4(10) limb would have cost us something: it would have made the automated steps in clause 22.2 arguably "required by other legislation", which is one of the three cases in which the PDPL removes a right to object, and clause 22.4 says that none of the three applies to a Respondent.

13.3 Article 4(3) is bounded by necessity, and we do not stretch it. It carries the case file, the parties' identities, service, the award, the court bundle and retention for the period in which an award may be enforced. It does not carry website measurement, the Clients section, operator alerts, or anything else that is not needed to bring or defend the claim. Each of those is dealt with separately below, and where no Article 4 case fits a purpose we narrow the purpose rather than widen the stated basis.

13.4 We do not rely on Article 4(9) for anything we do with a Respondent's data. Article 4(9) covers processing necessary to perform a contract to which the data subject is a party, or to take steps at their request. A Respondent has no contract with us and has asked us for nothing. The contract between the Claimant and the Respondent is where the contact details and the permitted channels come from as a matter of fact, and clause 14 explains that, but it is not a contract with us. Our basis for Respondent data is Article 4(3).

13.5 Our relationship with a Claimant or an account holder. Creating and running an account, taking a fee, issuing an invoice, and administering an assignment.

Legal basis: Article 4(9), for the engagement actually formed — the paid filing of a claim and the operation of the account through which it is done. We do not rest this on a Terms of Use, because no Terms of Use is in force and the platform asks nobody to accept one; clause 29.7 says so. The declaration a Claimant signs on filing is narrower than the purposes in this Part, and clause 25.6 says what that means.

13.6 The review text. We hold and reproduce the text of the public review.

Legal basis: Article 4(2) — Personal Data that has become available and known to all by an act of the data subject. The Respondent published the review. That basis covers the text of the review, its web address, and the identity of the reviewer as it appears in the review itself. It does not cover anything else about the Respondent: the name, the email address, the telephone number, the postal address, the identity document and the identity number were all supplied by the Claimant from its own records and are not public. Those rest on Article 4(3), and only while a claim is on foot. Where the review was published under a name, handle or display name that does not identify you, the connection between that review and you is likewise an assertion by the Claimant and not public data.

13.7 Security, authentication and abuse prevention. Sessions, one-time codes, device binding, rate limits, failed-attempt records and the log filter described in clause 11.6.

Legal basis: Article 4(10) — processing necessary to fulfil obligations imposed on us by other laws of the State. Articles 7(1) and 20(1) of the PDPL require us to secure Personal Data, so processing done to discharge that requirement is processing we are obliged to carry out. For security processing tied to a live Case we also rely on Article 4(3). We do not rely on Article 4(9) for security processing about a Respondent, because a Respondent has no contract with us, and that is precisely the case in which a contract-based basis fails.

13.8 Operating and monitoring the platform. Diagnosing errors, measuring availability, and keeping the service running.

Legal basis: Article 4(10) for the monitoring that the security duty in Articles 7(1) and 20(1) requires, and Article 4(9) for the account holder whose service we are keeping running. We are not able to found error monitoring about a Respondent on either limb with confidence, so clause 17.1(j) and clause 23.13 state what that provider receives and how it is reduced, and clause 18.6 records that the question of where it processes is unresolved. If counsel is not satisfied that a case applies, the answer is to narrow the processing and not to widen this clause.

13.9 Invoicing, tax and accounting records.

Legal basis: Article 4(10). PLM is not registered for VAT and issues an Invoice, not a Tax Invoice. The record-keeping obligation we presently rely on is Article 56 of Federal Decree-Law No. 47 of 2022 on corporate tax, together with the commercial books provisions of UAE commercial legislation. That is the one obligation in this clause that binds PLM itself rather than somebody else. The VAT invoicing provisions of Federal Decree-Law No. 8 of 2017 and Cabinet Decision No. 52 of 2017 will apply from the date any VAT registration of PLM takes effect.

13.10 The verification facility. Every document we serve carries a verification address and a code, so that a court, a review platform or the other party can confirm the document is genuine and unaltered. Clause 19.3 says exactly what each code discloses.

Legal basis: Article 4(3) and Article 4(10). A document that cannot be verified cannot safely be relied on in a ratification application under Article 55. You cannot opt out of the facility, because it is what makes the document capable of being relied on. You can and should treat the document itself as confidential.

13.11 Publishing a company in the Clients section.

Legal basis: consent. Only companies are listed; we do not list an individual. Clause 21.10 says how to withdraw it.

We have to tell you that the consent we take today does not meet the description the PDPL gives. Article 6 requires consent to be given in a clear, simple, unambiguous and easily accessible manner. The box a reader ticks does not mention listing, there is no way to decline, and the request is inferred from a value that is always set — clause 11.10 sets out all five weaknesses. So a company reading this should treat clause 11.10 rather than this clause as the accurate statement of what it agreed to, and any company already listed may have the listing removed by writing to us under clause 21.10 without giving a reason.

13.12 The Roster.

Legal basis: for holding the Roster record, performance of our contract with the Arbitrator and compliance with our own obligation to constitute a tribunal under Federal Law No. 6 of 2018. Publication of an entry rests separately on the Arbitrator’s consent, which the Roster records.. If there is a membership instrument between PLM and the Arbitrator, that is Article 4(9), for the performance of it. If there is not, the Roster record rests on Article 4(3), on the same footing as the appointment it exists to make. We say which rather than leave it to be assumed, because clause 13.4 applies the strict contract test to a Respondent and Part C has to apply one test throughout — and because clause 2.4 says an Arbitrator is not employed, instructed or paid by PLM, which is a fact that cuts against a contract-based basis rather than for it.

Consent for publishing the entry on the public Roster. If an Arbitrator withdraws consent to publication, the entry comes off the public page; the underlying record stays. Clause 21.10 applies.

13.13 Two bases we do not rely on. We do not rely on Article 4(1), processing necessary to protect the public interest, because UORA is a commercial service charging a fee. We do not rely on Article 4(7), processing necessary to protect the interests of the data subject, because serving a claim on a person is not done to protect that person's interests. We mention both because they would be the obvious places to reach for, and reaching for them would be wrong.

13.14 What we never do. We do not use Personal Data for advertising. We do not profile people. We do not score, rank or rate any person. We do not share Personal Data with anyone for their own marketing (see clause 16.8 for the position on sale). We do not run behavioural analytics on any page that carries a Case credential, and no analytics script of any kind is served on those pages; the public information pages of uora.ae carry the measurement described in clause 27. We do not copy live case data into test or demonstration environments, we do not use it in marketing material, and we do not use it to train or evaluate any automated or machine-learning system. Test data is synthetic.

14.1 Serving a document on a Respondent is the single most intrusive thing this platform does, and it is done without the Respondent's agreement. It deserves a clause of its own.

14.2 Where the contact details come from. They come from the Claimant. The Claimant declares, on the record and over its signature, that they are the contact details stated in the parties' contract, or given for communications under it. That declaration is versioned, digested and stored with the name, time and network address of the person who made it.

14.3 What authorises us to use them. The clause the parties adopted says that notices may be served by PLM as delegated person, by email, SMS and WhatsApp, to the contact details stated in the agreement, and that transmission to any one of them is valid and effective service under Article 24 of the Arbitration Law. That is a term the Respondent's own contract carries. It is not a term of any agreement between the Respondent and PLM. PLM is paid a fee for each stage of the procedure; the fee does not enlarge that authority.

14.4 What "effective service" means for your data. Service is effective at the first successful transmission to a contractual contact detail, whether or not the message is delivered and whether or not it is opened. The case page is a method of service under the Rules but is not a contractual contact detail, and is excluded from that calculation. This is the only construction the platform will accept: an administrator cannot select any other.

14.5 How time limits are calculated, and the one question about it we have not settled. Time limits are calculated from the instant of that first transmission. A period stated in days is added to the Dubai wall-clock time of the transmission. There is no next-day start, no evening cut-off, and no extension where the last day falls on a weekend or a public holiday.

Article 24 of the Arbitration Law provides all three of those as defaults, and they do not all sit in the same place, which is why we set it out rather than summarise it. The evening cut-off is in Article 24(1). Article 24(1) opens "Unless otherwise agreed by the Parties, the provisions mentioned in this Clause shall be applicable", so the parties may displace what is in that paragraph, and Sections 5.4 and 8.3 of the Rules are that agreement. The next-day start and the extension where the last day is a holiday are in Article 24(2), which carries no such opening words of its own. Whether an agreement displacing Article 24(1) also displaces the separate period-counting rule in Article 24(2) is a question we have not settled, and we tell you rather than assert the answer, because it is the question on which a 48-hour period that can expire at 23:43 on a public holiday turns. If the answer is that Article 24(2) cannot be displaced, our periods are shorter than the law allows. Clause 3.10 tells a Respondent how to ask for more time.

14.6 What we record. Every attempt, with the destination in full, the channel, the provider, the provider's identifier, the status, the time and the message itself. That record is not administrative housekeeping: it is evidence recited in a certificate of service, printed in a Service Log, and read by a court on a ratification application.

14.7 Delivery and read confirmations. Where a provider tells us a message was delivered, we record it. We do not measure whether you opened an email carrying a served document: the setting that would report it is switched off for every served document, deliberately, and the certificate of service does not state a delivery or read confirmation. Section 5.4 of the Rules says that such confirmations are recorded in the Service Log and stated in the Certificate of Service as corroboration. As the platform is built, the Service Log has the columns and the Certificate does not, and email opens are not recorded at all. We say so rather than repeat the Rules' description.

14.8 If every channel fails. Service is not effective, we record the failure, and we ask the Claimant for alternative contractual contact details. An administrator can then replace the contact details on the file. An administrator can change only the contact details, never the identity of the party. Replacement details must be evidenced from the parties' contract or from communications under it, and the substitution is recorded on the Case file.

14.9 If we hold a message back. If we suspend outbound messages for an operational reason, the message is recorded as held and not as sent, so no period starts from it. It is also not recorded as a failure, so nothing alerts us that the Case has stopped. A Case in that state is not advancing, and we do not claim that the platform detects it.

14.10 No SMS is sent today. The Rules provide for service by SMS and the platform supports it, but no SMS gateway is connected, so an attempt fails rather than being certified as service. Nothing in the platform reads an inbound text message either, so a reply to one would reach nobody. Where clauses 8.9 and 11.5 mention SMS they describe what would be recorded if it were used. A provider will be named in this policy before it carries a single message. Clause 29.8 withdraws the separate SMS notice that says otherwise.

14.11 Which channels are used, and when that can change. The channels available for a party are worked out afresh each time a document is sent, from the platform's own settings and the contact details on the file. They are not fixed to a Case when the Case opens. Clause 29.5 says what follows if we change a carrier or add a channel while your Case is live.

14.12 What that means for erasure. The service record is part of the record of a legal procedure. It cannot be deleted while it may be needed to establish that service was effected. Clause 21.7 says so plainly.

14.13 If your details are wrong. Tell us. Clause 21.6 explains what we can do and what we cannot.

15.1 This clause describes something that limits your right to erasure. We set it out in full rather than in general terms.

15.2 What the Journal is. Every procedural act on the platform is written to a single append-only record. Each entry contains the digital fingerprint of the entry before it, so the entries form a chain. Changing or removing one entry breaks every entry after it, and the break is detectable.

15.3 Why it exists. An arbitral award is enforceable because the record behind it is trustworthy. A record the operator can quietly edit is a record a party can allege was quietly edited. Federal Decree-Law No. 46 of 2021 treats the integrity of an electronic record as what gives it evidential weight. The Journal is how UORA can show that no procedural step was altered after the event.

15.4 As built today, it cannot be edited or deleted. The database refuses every update and every delete against the Journal, whoever asks, and the table is owned by a role the application does not hold. The Case identifier is part of what each entry is digitally fingerprinted over, so it cannot be blanked, and the Case record cannot be deleted because the Journal points at it. There is no administrator override and no maintenance route around it.

15.5 What we are changing. Holding personal data inside the chain is a design choice, not a requirement of the law on electronic records. The integrity purpose in 15.3 is met equally by committing a fingerprint of each entry's contents to the chain and holding the contents themselves in a store that can be erased. We intend to move to that design. When we have, entries written after the change will be erasable, and only entries written before it will carry the limit in 15.7. We are also extending the write-time redaction in 15.8 to the items listed there. This clause is an undertaking; if it is not being committed to, it should not be published.

15.6 What is in it. For every step: the state before and after, the event, the actor and their role, the time, the effects applied, the documents produced with their numbers and fingerprints, the case fields written, and the input that produced the step. Also: uploads and deletions of evidence, creation and change of accounts and roles, settings changes, exports, and the fact and metadata of an erasure.

15.7 Personal Data that is in the Journal and cannot presently be removed from it:

(a) the typed name of a person who signs a declaration;

(b) the network address and browser identification string of that person;

(c) the file name of every evidence file, as uploaded — file names frequently contain personal names;

(d) email addresses, unmasked, in entries recording an inbound email and in entries recording the creation or change of an account, including the address a changed account held before and after;

(e) the legal name and licence number of a Claimant organisation;

(f) the name, email, telephone and address of a configured Assignee, where a settings change is recorded;

(g) a Track B statement, and the passages of the review alleged to be false, which quote the Respondent;

(h) the signatory name recorded on an assignment election.

The items in (b), (c) and (d) are avoidable by the same write-time mechanism we already use for other fields, and we intend to extend it to them (clause 15.5).

15.8 What we keep out of it. Before anything is written, the platform strips out: the body text of a submission, signature images, identity document numbers, file contents, passwords, one-time codes, and bank account details. Free text over 2,000 characters is truncated; the Track B allegations at 15.7(g) are recorded in full. Where a notice is served, the destination address or number is masked before the entry is written. The record of an erasure is deliberately complete about documents and fingerprints and silent about people: it names no file and no destination.

15.9 One asymmetry we should name. We decided that a destination was too sensitive to commit to the chain and we did not make the same decision about the name of an uploaded file, even though a Claimant uploads a Respondent's identity document and names the file as it likes. So the masking in 15.8 is a real control, and it is not evidence that the Journal is generally minimised.

15.10 How this sits with the right to erasure. Not by pretending.

(a) We will erase Case content when the conditions in clause 20 are met. That is real: the review text, the contract references, the evidence files, the documents, the service records, the party records and the bank details on the Case all go, and the stored files are deleted.

(b) For entries written before the change in 15.5, we cannot erase them. We rely on Article 15(3)(b) of the PDPL, which excludes erasure where the request would affect claiming and defending rights, and on Article 15(3)(c), where erasure would contradict another law to which we are subject — here the integrity requirements that make an arbitral record capable of ratification under Article 55 of the Arbitration Law and challengeable under Article 53. Article 15(2) is itself subject to the legislation in force in the State. Those grounds hold only while a claim or its enforcement lives; when neither does, they lapse, and what then governs is clause 20.

(c) We minimise at the point of writing, which is the only point at which anything can be minimised in the present design. That is why clause 15.8 exists and why we intend to extend it.

15.11 What the Journal is used for. Verifying the integrity of the record, and answering a dispute about what happened in a procedure. Nothing else. It is not published, not served, not placed in a court bundle, and not sold or shared. It is readable by our administrators, subject to clause 23.9.

15.12 One further limit. The Journal is verified nightly against a stored watermark, and the head of the chain is also stamped into the metadata of an off-site database dump. The nightly check would detect an edit. It would not, on its own, prove that the newest entries had not been truncated, which is why the second copy exists. Nothing compares that second copy automatically; it is evidence for a restore, not a live alarm.

16.1 The other party to the Case. This is the point of the procedure. Served documents name both parties and quote the review. A party sees the documents served on them and the documents they filed, and not everything on the file: a request for anything else returns "not found", not "forbidden", because confirming that a document exists would itself disclose something. Some documents are served on one party only, and the Recovery Sharing Agreement is served on nobody.

16.2 The Arbitrator. The Arbitrator appointed to a Case sees the case file for that Case, and no other. A Roster member cannot open another member's file. One document is withheld from the Arbitrator by design: the Recovery Sharing Agreement, because it contains a Claimant's settlement position and bank account, which the tribunal deciding the claim has no business reading. The Arbitrator is not acting on our instructions. They decide for themselves how they handle the case material they receive, and they are answerable for it as a Controller in their own right. This policy does not describe what they do with it, and our erasure does not reach a copy they hold.

16.3 The Assignee. Where a claim is assigned, the Assignee becomes the Claimant, takes the claim absolutely and runs it in its own name. The Assignee is a person PLM designates in its platform settings; the Claimant does not choose it, and no assignment can be elected unless one is configured. An Assignee is designated as at the date of this policy. We do not name them here: the designation is provisional, it may change, and the identity of the Assignee is disclosed to a Claimant at the point an assignment is offered, which is the point at which it bears on a decision. On the platform as it is built a Permitted Assignee is a natural person rather than a company, and the platform expects an identity document for them on the same footing as any other party. The Assignee receives the Deed of Assignment, the Recovery Sharing Agreement and the case file it needs to run the claim. It is a Controller in its own right for what it then does, and our erasure does not reach a copy it holds. A Respondent is told who the Assignee is by service of the Deed of Assignment. We name the Assignee here as well, because Article 13(2) of the PDPL requires the recipients of Personal Data to be disclosed before processing begins, and the Assignee is the recipient of the whole of a Respondent's case file.

16.4 Courts, and the court bundle. Where an award is not complied with, the Claimant or Assignee may apply to the Dubai Court of Appeal for ratification under Article 55, and then to the execution court. We build the bundle; we do not file it, and we do not act as anybody's advocate. The bundle contains the award, the contract, the certificates of service, the Service Log with every destination in it, the review screenshots, the trade licence, the identity document of the Claimant's signatory, and the identity document of the Respondent where one has been filed. The evidence in the bundle is the original file as uploaded, so any information hidden inside a photograph travels with it (clause 8.4).

16.5 Review platforms. Where an award orders removal or amendment of a review and it is not complied with, the platform produces a letter for the Claimant or Assignee to send to the review platform, and a second version enclosing a court order once one is recorded. The letter as drafted encloses the award itself and names the platform to send it to — Google, Airbnb, Booking.com, Tripadvisor or Trustpilot. Sending it is the party's act and not ours, but we draft it and we name the recipient, so we do not describe these as platforms the party found for itself.

Article 48 of Federal Law No. 6 of 2018 makes an arbitral award confidential and permits its publication, in whole or in part, only with the written approval of the parties. Section 14.1 of the Rules is the parties' agreement that confidentiality does not prevent disclosure for a takedown request, and that is what we rely on. Two questions about it are not settled, and we would rather name them: whether an advance agreement given by incorporation into a contract is "written approval" for the purposes of Article 48, and whether enclosing the whole award, rather than the operative direction alone, is within what Section 14.1 permits. Clause 18.9 treats the sending as a transfer outside the UAE and records that we have not settled a basis for it either.

16.6 Where the law requires it. We will disclose Personal Data where a court of competent jurisdiction orders it, where a UAE regulator with authority over us requires it, or where a law of the UAE requires it. We will satisfy ourselves that the demand is valid and no wider than it needs to be, and we will tell you it has been made unless we are prohibited from telling you.

16.7 Service Providers. Named in clause 17, which states for each what it receives, where it processes, and whether it acts on our instructions under a written contract.

16.8 We never sell Personal Data, and we never share it for anyone else's marketing.

16.9 Operational alerts to the operator. When a fee is received, and when an arbitration clause is generated, an alert is sent by WhatsApp to a single mobile telephone controlled by the operator. The payment alert carries the case number, the stage, the amount, and whether the payer was the Claimant or the Respondent. It carries no party's name, no e-mail address and no other contact detail. Sending it is still a transfer outside the UAE on the route clause 18.3 describes, because the message travels through the messaging provider named in clause 17.

Earlier versions of this policy said no alert was being sent, because the messaging provider had not approved the message templates. That is no longer true, and we correct it rather than leave it: both templates were approved on 09-09-2026, the destination is set in our production configuration, the messaging channel is live, and the alert is fired from four places in the platform. So the alerts are being sent today. Until 28-09-2026 the payment alert was additionally built from the payer's name and e-mail address; that content has been removed from what is sent, because a case number, a stage and an amount are enough to alert an operator. The clause above describes what the alert carries now. As at 28 September 2026 the destination configured on the running service is a single mobile telephone number in the United Arab Emirates, belonging to a member of our operations staff, and the messaging mode is live. It is one number, not a group or a distribution list.

17.1 The following receive Personal Data from us. Each entry says what it receives and where it processes. Except where the entry itself says otherwise, each acts as our processor, on our instructions, under a written contract. Two entries say otherwise, and the qualification is in the entry rather than in a footnote.

(a) Microsoft — Azure, application hosting and database. Receives: everything the platform stores and processes. Region: UAE North.

(b) Microsoft — Azure, file storage. Receives: every uploaded file, every issued document and every court bundle. Region: UAE North, in a zone-redundant account. Geo-redundant database backup is not enabled, so the database is not replicated to another region.

(c) Twilio (SendGrid) — outbound email, as our primary email carrier. Receives: the recipient's address and any copied address, the subject, the full bilingual message in HTML and plain text, any attachment up to 25 MB — which for a served document is the document itself — and identifiers for the case, the document, the party role, the attempt and the template. This is the channel through which served notices, certificates and awards leave the platform, so it is the largest single flow of case content out of the UAE and it is the ordinary path rather than an exception. Click tracking is permanently off, and open tracking is off for every served document. Region: outside the UAE. See clause 18.5.

(d) Microsoft — Azure Communication Services, outbound email as a fallback and the WhatsApp business channel. Receives, for email: the same categories as (c). The fallback is consulted only for mail that is not service of a document, which in practice means sign-in links, one-time codes and courtesy notifications; for that mail, whether opening is reported depends on a setting on the sending domain that this policy cannot state. Receives, for WhatsApp: the recipient's number, the template values, and the address from which a document is to be fetched. The resource is stated to hold data in the UAE for email; we do not assert the same for the WhatsApp leg, because what happens on that leg before the message reaches Meta is not something we can evidence.

(e) Microsoft — Azure monitoring. Receives: operational log records after the filter in clause 11.6, request routes with the secret parts removed, error details, and case, user and request identifiers. Retained 90 days. The workspace is shared with other products of the same group — clause 11.8. Region: UAE North.

(f) Microsoft — Azure Translator, a drafting aid available to an Arbitrator. Receives: passages of text an Arbitrator chooses to translate, which may be draft award text in a live arbitration. Nothing it returns enters a document unless the Arbitrator writes it there. The platform calls the global endpoint of that service, not a regional one, so the region is not settled — see clause 18.6.

(g) Meta Platforms — WhatsApp Business Platform. Receives: the recipient's telephone number, the fact that they are party to a dispute, the values printed in the message template, and, where a document is attached, the served PDF itself, which Meta fetches for itself over the public internet. A reply you send us on WhatsApp passes through the same infrastructure before it reaches us. THIS ENTRY IS AN EXCEPTION TO THE CHAPEAU: we have no contract with Meta at all. Our contract is with Microsoft, which acts as the WhatsApp business solution provider, and Microsoft's arrangements with Meta are not ours. So Meta is not our processor under any contract of ours, and we do not describe it as one. Region: outside the UAE. See clause 18.3.

(h) Stripe — payment processing. Receives: the case identifier, the case number, the stage, the organisation and payment identifiers, the fee description, the amount, the payer's email address where we hold one, the case's language, and for a settlement the payer's role and the collection and declaration identifiers. Card details are entered on Stripe's own page, so Stripe also receives your network address and device directly from your browser and they never reach us. The entity we contract with is Stripe Payments Europe, Limited, which is established in Ireland, so this is a transfer outside the UAE. The provider’s own infrastructure extends beyond Ireland, including to the United States, and we do not assert a single processing location for it. See clause 18.6.

(i) Netlify — website hosting, and a proxy that carries all browser traffic to our service. Receives: the full content of every request and response between a browser and the platform, including sign-in credentials, case content, uploaded files and downloaded documents, together with your network address. The encrypted connection terminates at that provider's edge network before the request is forwarded to the UAE. Because a respondent link and a verification link carry their credential inside the web address itself, those credentials are in the request lines that network sees. Region: a global edge network, outside the UAE. The provider does not publish the individual locations that serve a given site, so we cannot name them. See clause 18.4.

(j) Functional Software (Sentry) — error monitoring. Receives: exception details and stack traces, the request path, a request identifier, a case identifier and a user identifier, on a failed request. Request bodies are deleted before sending, the personal-data scrubber runs over the whole event, and the provider's own option to collect identifying data by default is switched off. If the scrubber itself fails, the event is sent unscrubbed rather than dropped. Region: the United States. See clause 18.6.

(k) Xero — accounting. Receives: the paying organisation's legal name, its UORA identifier, its tax registration number, its email address and its street address with emirate, and the invoices and credit notes we issue, which cite case references. Where the Claimant is an individual, that organisation record is a natural person's record, so this is a transfer of a natural person's data. A setting exists that would also send the invoice document itself as an attachment. Region: outside the UAE. The provider’s published material states that it replicates data between data centres in different locations and does not name them; its platform runs on Amazon Web Services, principally in the United States, and it processes some data in New Zealand, where it is headquartered. We state what the provider publishes and do not assert more than that. See clause 18.6.

(l) Google LLC — Google Analytics 4, on the public information pages only, and only where a reader has agreed under clause 27.1. Receives: your network address, the cookies named in clause 27.3(g), the shape of the page address rather than the address itself, the address your browser reports as having linked you here, and the ordinary device and browser characteristics a browser sends. It receives nothing from any page that carries a Case credential, and no identifier of yours that we hold. Google's advertising features are not enabled, so nothing here is used to build an advertising profile of you. Region: outside the UAE. Whether Google acts as our processor for this, or as a Controller in its own right for part of it, is something we are confirming rather than asserting. See clause 18.8.

(m) Microsoft — Exchange Online, which receives inbound mail addressed to our published addresses at uora.ae. That means it receives whatever a data subject writes to us, including a request under clause 21. Until 28 September 2026 this mail passed through a third-party forwarding service whose identity we had not established. The domain’s mail is now delivered directly to Microsoft, under the same contract as (d) and (e), and the forwarding service has been removed. The data location of these mailboxes follows our Microsoft 365 tenant; we are confirming it and will state it here rather than assert it now.

17.2 Backups. The nightly database dump is written to a separate storage account, which holds a copy of the whole case database. Region: UAE North, the same region as the live database.

17.3 What a Service Provider keeps after we erase. Our erasure removes data from our own systems. It does not reach copies held by the providers above. Each keeps records for its own periods: our monitoring workspace for 90 days; the others for the periods their own terms set. Where our contract with a provider allows us to instruct deletion, we will. For the WhatsApp channel we cannot, and we say so rather than imply otherwise. Our accounting provider is not asked to delete an attachment, and the integration has no ability to delete one.

17.4 Source code and deployment, which is not on the list above. Our source code and our deployment pipeline are hosted by GitHub (Microsoft), which receives the source code and the identifiers of the people who work on it. No production Personal Data is sent there. We mention it for completeness and we do not describe it as a processor of Personal Data, because processing on our instructions is not what it does.

18.1 What stays in the UAE. The application, the database, file storage and the secrets that protect them are in Azure's UAE North region, and no file is reachable without a link we sign that expires within an hour. The communication service that sends our fallback email is stated to hold data in the UAE. Everything else in this clause leaves.

18.2 Article 22 of the PDPL permits a transfer to a country the Bureau has approved, and no such approval has been made. So every transfer below rests on Article 23, and none rests on adequacy.

Article 23 allows a transfer in defined cases. One of them is a contract obliging the recipient to adopt the measures, controls and requirements of the PDPL itself. On its terms that case is addressed to establishments operating in countries where there is no data-protection law, so whether it is available at all for a recipient in a country that does have one is a question of construction rather than a plain reading of the text, and we do not present it as plainly available. Every destination named in clause 17 is in a country with a data-protection law. The other cases include a transfer necessary to establish or exercise rights before judicial entities, and a transfer to which you have given express consent.

A standard commercial data-processing addendum does not contain the undertaking the contract case describes, and no standard clauses have been issued, so each contract has to be written specially. Where we have not settled which case is available for a recipient, the line below is blank rather than filled in.

18.3 WhatsApp. This is the most significant one. When a notice is sent by WhatsApp, the message and, where a document is attached, the served PDF itself, pass to Meta outside the UAE. The PDF is the legal instrument: it names both parties, quotes the review, and states what is claimed. The document is not sent as bytes — we mint a temporary web address valid for 30 minutes and Meta fetches the file over the public internet. That address requires no password, so anyone holding it during those 30 minutes can read the document. Uploaded evidence and identity documents do not travel this way; only the served document does. A reply you send us on WhatsApp travels the same route in the other direction. WhatsApp is often the only channel that reliably reaches a person in the UAE, which is why it is used. The operator alert described in clause 16.9 travels this route too, and carries a payer's name and email address.

Basis relied on: Article 23(1)(c) — the transfer is necessary to establish or exercise rights before judicial entities — read with the ratification and enforcement of the award before the Dubai courts, since an arbitral tribunal is not itself a judicial entity. The parties' own contract identifies WhatsApp as a channel for service and states the number to be used. We cannot rely on the contract case for Meta, because we have no contract with Meta at all — clause 17.1(g). The necessity of sending the document itself, rather than a notification and a link to the case page, is a question we have not settled, and the case page is itself a method of service under the Rules. The operator alert in clause 16.9 does not fall within this basis at all, and it is one of the reasons we intend to strip the identifying data out of it.

18.4 Website and browser traffic. Because our website's proxy sits in front of the service, the content of browser traffic — not merely its metadata — passes through a global edge network outside the UAE, together with the case and verification credentials described in clause 17.1(i).

Basis relied on: the appropriate contractual safeguards limb of Article 23, under the data processing terms the provider offers and we have agreed. We do not rely on your consent for it, because a Respondent reaching the case page has agreed nothing, and a basis that only covered Claimants would not cover the traffic this clause is about.

18.5 Email. Our primary email carrier is outside the UAE, and it carries the served documents themselves. This is not a narrow fallback: it is the ordinary path by which a Cure Notice, a Request for Arbitration, a certificate of service and an award leave the platform.

Basis relied on: the appropriate contractual safeguards limb of Article 23. We carry this transfer under the data processing terms the carrier offers and we have agreed. For a served document we rely in addition on the limb covering a transfer necessary to establish or exercise a right before a judicial entity: service is the act that starts a procedural clock, and the award it leads to is ratified and enforced before the Dubai Courts.

18.6 Payments, error monitoring, translation and accounting. Four destinations are not settled and must be before this policy is published: the contracting entity, account country and processing region of our payment provider; the data region of our error-monitoring provider, which offers no UAE region; whether the translation service processes text in the UAE, which on the present configuration it does not, because the platform calls the global endpoint and the region travels only as a credential header; and the processing region of our accounting provider. Until each is confirmed, this policy does not assert that any of the four is processed in the UAE.

18.7 Recipients' own mailboxes. When we serve a document by email or WhatsApp, it arrives in whatever mailbox or handset the recipient uses, wherever that is hosted. That is a consequence of serving it, not a transfer we choose. Mail sent to us is different: it reaches a forwarding provider first — clause 17.1(m).

18.8 Website measurement, as described in clause 27.2(b). This transfer happens only where you have agreed to it under clause 27.1, and only from the public information pages. It is the one transfer in this clause that you switch on and can switch off: withdraw your agreement from the link in the page footer and nothing further is sent. It carries your network address, the shape of the page you are reading, and the address your browser reports as having referred you; it never carries a Case credential, because the script is not served on any page that has one. If the recipient is a Controller in its own right rather than our processor, as clause 17.1(l) says we are still confirming, the analysis of this transfer changes and we will change it.

18.9 Review platforms. Where the letter described in clause 16.5 is sent, the award travels to a review platform outside the UAE. We draft the letter and name the recipient.

Basis relied on: not settled, and this is the transfer on which we are furthest from an answer. Earlier versions of this policy relied on Section 14.1 of the Rules read with Article 23(1)(c). Neither limb of that works. Section 14.1 is an agreement between the two parties about confidentiality, which answers Article 48 of the Arbitration Law; it is not the data subject's express consent to a transfer outside the UAE, which is what the consent case in Article 23 requires. And Article 23(1)(c) covers a transfer necessary to establish or exercise rights before judicial entities: a review platform is not a judicial entity, and a takedown request is not a proceeding before one — which is the same reasoning that leads clause 18.3 to route the WhatsApp transfer through the courts rather than through the tribunal. So we show the blank: we identify no basis under Article 23 for that transfer and we do not assert one. This is why the platform does not send a takedown request itself — the Claimant does, in their own name, from their own account.

18.10 Inbound mail. Mail addressed to our published addresses reaches a forwarding provider whose location we have not established, before it reaches us. That includes a request under clause 21 and a complaint under clause 28.

19.1 The Roster. Display name and biographies of Arbitrators whose entry is published and active. No contact details, no nationality, no address. An entry is withheld from the public page unless it has been marked for publication, is active, is free of placeholder text and carries the particulars an award requires, and the query that builds the public page cannot return anything else. As at 28 September 2026, one Arbitrator entry is published: a display name only, with no biography recorded.

19.2 The Clients section. Company legal name and sector, and nothing else — not your name, not contact details, not whether the company has filed a case, and not the existence, subject or outcome of any case. A listing discloses that the company has adopted the UORA clause, and nothing beyond that: we know that a company name was typed into a public form and that an administrator approved the listing, and we do not verify the underlying contract, so we do not describe a listed company as having been confirmed to have adopted the clause. It requires a recorded consent and an administrator's approval, and only companies are listed. Clause 11.10 sets out what is weak about the consent. As at 28 September 2026, no company is published.

19.3 The verification page at uora.ae/verify. Every document we serve carries a verification address and a code, so that a court, a review platform or the other party can confirm the document exists and has not been altered.

(a) The short code is printed in the footer of every page of a served document and encoded in a QR code, so it travels with any copy, forward or screenshot. It discloses: the existence, identifier, document number, case number, version, date and digital fingerprints of the document; whether it was served and when service took effect; the certificate number; the Rules version; and, for a document issued by the tribunal, the name of the appointed Arbitrator. It does not disclose the content of the document, the parties' names, the review, contact details or amounts.

(b) A second, longer code exists in our records and unlocks more: the parties' names and the times at which each party was served, per channel. Contact details stay withheld even then. That code is not printed on any document we issue. The verification page nonetheless invites a reader to enter the code printed inside the document, so as the platform stands the invitation cannot be followed and the party-level disclosure cannot be reached by a reader of the document. We will either print the code or remove the invitation, and this clause states the position rather than describing a code you could find.

(c) Neither code can be revoked or given an expiry date. Anyone who obtains a copy of the document, by any means, can use the printed code for as long as the document exists. Treat the document itself as confidential.

(d) An unknown code and a real code return an identical page, so the facility cannot be used to find out whether a case exists.

19.4 Case examples. We do not publish any case example, redacted or otherwise, that concerns an identified or identifiable Respondent, unless that person has consented in writing and we hold the record of it. Images of court documents from a completed case are presently published on our home page; this clause and those images cannot both stand, and the images come down unless the consent is obtained and recorded.

19.5 Confidentiality of the proceedings. The proceedings are confidential under Section 14.1 of the Rules, to the extent the law permits, subject to the exceptions that section names. The verification facility in 19.3 is one of those exceptions and is limited to what 19.3 describes.

20.1 Read this clause with clause 20.10. We have two automatic deletion jobs, not a retention programme, and the two rules most people would expect — deletion at the end of the retention period, and deletion of an inactive file — are the two we do not operate.

20.2 A Case that closes. We keep the Case file while the Case is live and then for a retention period after it closes. That period is ten years. It reflects the period within which an award may be ratified and enforced and a claim on the underlying obligation may be brought; we have not yet identified the instrument and article that fix it, and clause 1.4 means we say so rather than imply a statutory source. What we can say is that it does not mirror the commercial limitation period: Federal Decree-Law No. 50 of 2022 reduced that period from ten years to five with effect from 2 January 2023. The ten years is therefore a conservative operational choice of ours, made so that a Case outlasts any period in which it could still be needed, and not the reflection of a statutory figure. We are taking advice on it and will state the position here once we have it. The period does not run from the filing of the claim; it runs from closure. It is a figure held in our own configuration, which means an administrator could change it without anything else changing, and the platform will not accept a figure below six years. We undertake not to lengthen or shorten it without publishing a new version of this policy under clause 29.4.

An identity document filed as evidence is on that same clock and no faster: no rule treats it differently from a screenshot. That is a decision and not an oversight, because the document is evidence in a matter that may be enforced for ten years, but it means a government identity document may be held for ten years after a Case closes.

20.3 A Case that closes without an award. Where a Case closes because the review was amended or removed, because it was rejected, because a window lapsed, or because it was withdrawn, there is no award to challenge, ratify or enforce and the ten-year justification does not apply. We apply the same ten-year period to them, so that one rule governs every Case whatever its outcome, rather than a shorter period that would have to be justified case by case.

20.4 A Case that never closes. Both of our Case rules run from closure, and many Cases stop rather than close — a claim abandoned before it is filed, a claim left between steps, a Case where no further step is taken. Thirteen of the states a Case can be in are not closing states and have no sweep of any kind. A Case in one of them has no retention period at all and is held until it is erased by hand. Such a Case is held on the same ten-year basis, measured from the last step recorded on it. We say plainly that no automatic sweep enforces this yet: the platform opened in 2026 and no Case has approached the period, and we will build the sweep before one does. Until we have, you may ask us at any time to erase a Case on which nothing has happened, and we will.

20.5 After 365 days from closure, the stored files move to slower, cheaper storage. Nothing is deleted at that point, nothing becomes harder for us to read, and only the speed of access changes. It is a cost measure and not a privacy measure, and no Case has yet reached it.

20.6 What erasure of a Case actually does. In one operation we:

(a) record the fact of the erasure in the Journal, with document numbers, fingerprints and counts, and with no file names, destinations or names of people;

(b) delete the party records, the service records, the certificates of service, the submissions, the evidence records, the signatures, the documents, the bundles, the award drafts and awards, the compliance records, the objections, the appointments, the settlement declarations, the enforcement records, the deadline extensions, the consent records, the short links, the sign-in links, the one-time codes, the sessions and the reminders;

(c) clear the payment notes;

(d) blank the case content: the review text and address, the review reference, the contract references, the Track B allegations, the working copy of the claim form, and the bank account details held on the Case;

(e) then delete the stored files themselves — the evidence originals, the display copies, the document PDFs and their sources, and the bundles.

20.7 What survives an erasure, and why:

(a) The Case record itself survives as an identifier: a case number, a set of dates, a set of fingerprints, the erasure details, and also the Claimant organisation that brought the proceeding, the account that opened it, and any court or execution reference. Those references identify people, so the surviving record is not anonymous, and we do not describe it as anonymous. It survives because the Journal points at it and the Journal cannot be broken.

(b) The invoice record survives as a tax record, and so does any credit note issued against it, together with the structured copy of what was printed on each (clause 8.6), reduced to the fields a tax record needs. Three things follow, and the first of them corrects what earlier versions of this policy said.

First, the case caption on the retained copy is rewritten, in the same operation as the deletions, so that the erased party is shown as "[erased]", and the issued files themselves — the PDF and both language versions of the web page — are destroyed. What is kept is the information from which the document can be reprinted. Earlier versions of this policy told an erased Respondent that they were still named on the retained invoice for the whole accounting period. That is not what the platform does, and we withdraw it: a statement to a data subject that an erasure achieves less than it does is as much a defect as the opposite, and it might have deterred somebody from asking at all.

Second, nothing else about the erased party survives on that record. The list of fields the platform is allowed to keep contains no field about a Respondent at all, so the name, address, email address, telephone number and identity details are gone from it.

Third, what does survive is the paying party's own details: legal name, address, trade licence number, tax registration number and billing email address. Where the paying party is a company, those are not personal data about an individual. Where the Claimant is an individual rather than a company — which the Rules permit and clause 6.5 describes — they are that individual's own personal data, kept for the period in clause 20.8(g), and an erasure requested by a Respondent does not reach them.

(c) The payment record survives, as a tax record, with its free-text notes cleared.

(d) An Arbitrator's signature image survives, because it is stored against the person and reused. Deleting it would blank that Arbitrator's signature on every other case they ever signed. The Case's own signature record is deleted.

(e) Journal entries written before the change described in clause 15.5 survive. Clause 15 explains why, and clause 15.7 lists what is in them.

20.8 Other retention periods:

(a) Failed password attempts: deleted 24 hours after the last attempt.

(b) Abandoned sign-ups: deleted after 30 days. This is narrower than it sounds. It reaches only an account that self-registered, never verified an address, never signed in, holds no password, was never touched by an administrator, has no record of who created it, holds no role beyond claimant, and has no organisation membership, live invitation, case, session or Roster entry. Any account outside that description is kept — see (h).

(c) A sign-in link stops working after 15 minutes and a one-time code after 10 minutes. The record that one was issued, and the address or number it was sent to in readable form, is kept beyond that. Where the record belongs to a Case it is deleted when the Case is erased. Where it belongs to an account, nothing deletes it, so there is no period we can state.

(d) Session records, including network address and browser identification string: kept while the account exists, and deleted with the Case for a Respondent session. We list your sessions from the last 30 days to you on request.

(e) Case access tokens: 90 days, with a fresh one issued on each document served, and revocable under clause 21.11.

(f) Operational logs and telemetry: 90 days in the monitoring workspace.

(g) Invoices, credit notes, payment records and the accounting record: seven years from the end of the relevant tax period, extended while an audit or a dispute about them is live.

(h) Account records and organisation records: retained while the account exists. An account is deactivated rather than deleted, because case records, the Journal and Roster entries refer to it, so in practice a verified account's record is kept indefinitely. What sits on the account record is kept with it, including the cash-payment permission and write-off reason described in clause 9.2. Clause 21.12 says how to ask us to close an account and what survives.

(i) A withdrawn Clients-section listing: the record that consent was given and withdrawn is retained, unpublished, so that the company is not listed again by mistake.

(j) Service attempt records, inbound messages, short-link records and settlement declarations: held as part of the Case file and erased with it.

(k) The register of requests under clause 21: your name, the address you wrote from and the note identifying the matter are removed 90 days after we close the request, leaving the reference, the right asked for, the dates and the outcome. A request we have not closed is not reached by that rule, so it keeps your details until it is closed.

(l) Public-site page and control records, as described in clause 11.11: 120 days. That period reaches those records and nothing else; in particular it does not reach the download records in clause 11.14.

20.9 Seven categories are not covered by any retention rule, and we say so rather than imply otherwise. None of them is reached by Case erasure, because Case erasure is scoped to a Case, and none is reached by any sweep:

(a) the trade licence and the identity document of a Claimant's authorised signatory, held against the organisation (clause 6.6);

(b) records of clause generation (clause 11.9), and a Clients-section listing record (clause 11.10);

(c) a payout bank account held as a preference (clause 6.7), including the IBAN;

(d) the history of every email address an account has ever held, unmasked (clause 6.3);

(e) an Arbitrator's Roster record, nomination records, and any instrument issued about a person rather than about a Case (clause 10.4);

(f) an invitation to join an organisation's account, and the address it was sent to, whether or not it was ever accepted (clause 6.8);

(g) the record of a download of a published document, which for a signed-in reader names the account and the organisation and says which version was taken (clause 11.14).

Earlier versions of this policy listed five of these. The list has grown twice because we kept looking, and it may grow again.

We intend to add a retention rule for each, keyed to closure of the account. Until we have, the honest answer for all seven is that they are held indefinitely, and you may ask us under clause 21 to remove them, subject to clause 21.7. One thing has to be said about that, because clause 21.7(g) offers you the route: there is no route in the product for any of these seven, and no script for any of them. Removing one means an administrator working directly against the database by hand, and for an organisation document a separate deletion of the stored file, which our erasure tool does not cover. We will do it, and we will record that we have. It is also why we would rather build the rules than rely on the undertaking.

20.10 Erasure at the end of the retention period does not happen. The job exists and is wired up, but it is switched off by default, the switch has never been set, and no Case has ever been erased by it. Even if it were switched on today it would select nothing: it looks for Cases closed longer ago than the retention period, the platform has been live since September 2026, and on a ten-year period the earliest Case it could reach arises in September 2036. So erasure at the end of the retention period is a capability and not a practice, and this policy does not describe it as automatic. Erasure on a valid request, and on a court order, is available now.

20.11 An erasure on request is done by hand. There is no route in the product by which you can erase a Case yourself, and no automated process. An administrator runs it, having to confirm the case number, and records which of four grounds it was done on. We say this because "processed by our systems" would not be true.

20.12 We do not erase a Case while a court or execution reference is recorded against it, because the court file may still need it. That extension has no outer limit in our code: somebody has to record that the court file is finished with. There is no standing review of the Cases held on this ground, and we do not describe one — there is no job, no register and nobody named to do it. If you ask us whether a Case of yours is still held on this ground, we will tell you, and we will look at whether it still needs to be.

20.13 Erasure is not instantaneous, and the honest date is later than the date we act. Deleted files remain recoverable in the storage service's own soft-delete window, the database has a point-in-time recovery window, and nightly backups hold a copy. We record, with every erasure, the date on which those residual copies clear — no later than 35 days after the act — and that is the date we will quote to you, not the date of the act.

20.14 One class of stored file is beyond our erasure. If a file's bytes were written to storage and the database record for it failed to be created, the file has no record pointing at it. Our erasure walks the records, so it cannot see such a file, and our storage check does not look for them either. We cannot certify that no such copy of your file exists.

20.15 Erasure is by UORA, not from the world. A court file that references the Case is a court record. A review that is still published is still published. A copy served on the other party is theirs. Clause 17.3 states the position for our Service Providers, and clauses 16.2 and 16.3 for the Arbitrator and any Assignee.

21.1 Under the PDPL you have the following rights, and you do not need an account to use any of them. A Respondent has the same rights as a Claimant, except where 21.5(e) and 21.8 say otherwise. Some of these rights apply in some situations and not others; if you ask us to do something we cannot do, we will tell you why and which provision we rely on.

(a) The right to be informed about how your data is processed, and to obtain a copy of it (PDPL Article 13).

(b) The right to receive your data in a structured, machine-readable form, and to have it transferred (Article 14), where processing rests on your consent or on a contract you are party to.

(c) The right to have inaccurate data corrected, and the right to erasure (Article 15).

(d) The right to restrict processing (Article 16), including where you contest the accuracy of data, for a period allowing us to check it.

(e) The right to object to processing (Article 17), in the three situations that article covers.

(f) The right in respect of automated processing, including to require that a person reviews an automated decision (Article 18). See clause 22.

(g) The right to withdraw consent, where we rely on consent (Article 6). Withdrawing consent does not affect what was done before you withdrew it.

(h) The right to complain to the Bureau (Article 24).

21.2 How to ask. Write to us at the address in clause 2.5. Tell us what you want and, if it concerns a Case, give us the case number from the document you received. You do not need to give a reason, and you do not need to use any particular form of words. It is free.

21.3 Proving who you are. We will ask you to confirm your identity before we act, because these records concern a dispute between two parties and disclosing one party's data to the other would be a breach in itself. For a Respondent with a live Case, the simplest route is the one-time code sent to a contact detail already on the file. If that route is not open to you — because the contact detail is not yours, or because the Case has been erased — write to us with enough information to identify the matter and a copy of an identity document, and we will consider it. If we cannot establish that you are the person the data is about, we will tell you so and explain what we would need.

21.4 How long we take. We will acknowledge your request within 5 business days and respond within 30 days of receiving it, both counted from when your request reaches us rather than from when we register it. Neither period is set by the PDPL: the PDPL prescribes no response period for any of these rights, and these are our own undertaking. We will honour them as such, and if the Executive Regulations later set a period we will align to it.

21.5 What an access request produces. You are entitled to all the Personal Data we hold about you, not only the documents served on you and not only the records of things you did.

(a) For a Case, our export tool produces: our identity as Controller and the basis on which we process; your party record in full, including superseded versions; the Case; your submissions, with the network address and browser identification string recorded against them; the service attempts made on you, including the destinations used; the documents served on you and the documents that concern you; your evidence, including an identity document of yours that the other party filed; your consent records; the metadata of sign-in links sent to you; and Journal entries recorded against your role.

(b) That tool does not see everything. It is scoped to one Case and does not cover your signature record and the network address and device recorded against it, the working copy of the claim form, your sessions, one-time codes, a payout account, your email address history, organisation documents, an invitation sent to your address, the records of documents you downloaded from our site (clause 11.14), the register of your own previous requests, or website measurement records. Those we compile by hand on request. We would rather tell you the tool's boundary than describe its output as everything we hold.

(c) Where a record contains another party's Personal Data as well as yours, we provide it with their data redacted. We never include our own credentials.

(d) We do not search backup copies, and Service Providers hold their own copies which we do not produce. Clauses 17.3 and 20.13 explain.

(e) Transfer to someone else in a machine-readable form is available under Article 14 only where processing rests on your consent or is necessary to perform a contract you are party to, and is carried out by automated means. For a Respondent neither gateway opens, because you gave no consent and are party to no contract with us. We will still give you your data in a machine-readable form if you ask, as a courtesy, and we say that it is a courtesy rather than describing it as an Article 14 right.

21.6 Correction, and telling us we have the wrong facts.

(a) If a contact detail or another factual detail about you is wrong, tell us and we will correct it without undue delay. On a live Case, correction is made by adding a new record and marking the old one superseded, not by overwriting, because what was served and where is a fact about the past.

(b) If your objection is that the other party's account of the review or of the transaction is wrong, that is the substance of the dispute and we cannot decide it. We will record your version alongside theirs on the Case file, and it will be visible to whoever decides. Say it in your statement of position or your defence, where it counts.

(c) If you say we have the wrong person, tell us and say so on your case page. Before an Arbitrator is appointed, an administrator will consider it and will tell you the outcome and the reasons. If an Arbitrator has been appointed, it is for the Arbitrator, and we will put your statement before them. Either way we record the objection on the file. We do not substitute one party for another as a data correction.

(d) If you say you have no contract with the Claimant, or that your contract contains no clause adopting the Rules, that is not merely part of the dispute: it goes to whether we may hold your data at all, because our basis for holding it is that a claim can be brought. Tell us at the address in clause 2.5. We will record it on the Case file, notify the Claimant and require it to produce the clause, and tell you the outcome. If it cannot produce it, we will not continue to process your data on that basis.

21.7 Erasure — what we can and cannot do. We will erase your Personal Data when the reasons for holding it have ended and no other rule requires us to keep it. We will not be able to erase it in the following cases, and we would rather tell you now than tell you in a refusal letter. In each case we rely on Article 15(3)(b), which excludes erasure where the request would affect claiming and defending rights, or Article 15(3)(c), where erasure would contradict another law to which we are subject.

(a) While a Case is live, or while an award may still be challenged, ratified or enforced. That is the period in clause 20.2. Article 16(2) also allows you to require us to keep data beyond the purposes of processing where you need it to establish or defend a right, and some people will want that rather than erasure.

(b) Invoices, credit notes and accounting records, for the period in clause 20.8(g). Clause 20.7(b) says exactly what is on those records after an erasure and what is not, including that the erased party's name is replaced on the case caption rather than kept.

(c) Journal entries written before the change in clause 15.5. Clause 15 sets out what is in them, why, and what we intend to do about it. We will tell you specifically which of your data is in them if you ask, and clause 21.5(a) covers them in an access request.

(d) The Case identifier record described in clause 20.7(a).

(e) Where a court reference or an execution reference is recorded against the Case — clause 20.12.

(f) A copy that has no database record pointing at it — clause 20.14.

(g) Not a refusal: the seven categories in clause 20.9 are not reached by any automatic erasure, and we will remove them on request. Clause 20.9 says how that is done, which is by hand against the database, because there is no route in the product for it and no script.

21.8 Objection. Article 17 of the PDPL gives a right to object in three situations: direct marketing, including profiling for it; statistical surveys, unless the processing is necessary to serve the public interest; and processing carried out in breach of Article 5. We will not pretend it is wider than that. So you cannot use Article 17 to stop us processing your data for an arbitration unless you can show a breach of Article 5, and we say so plainly rather than implying a right we would then refuse. What Article 17 does squarely cover here is the Clients section and any marketing message, and for those an objection is absolute, needs no reason, and can be made without an account. Restriction is a separate right and clause 21.9 deals with it.

21.9 Restriction. You can ask us to restrict processing, and we will consider each request on its facts. Where processing is necessary to conduct or defend a legal claim, or is limited to storage, or is necessary to protect a third party's rights, the PDPL permits it to continue. In practice, a restriction on a live Case means we mark the disputed record as disputed, notify the Claimant and the Arbitrator that it is disputed, and limit our use of it to storage and to what the procedure itself requires. We cannot stop serving documents on a party, because that would defeat the procedure and would remove your own opportunity to answer. We will tell you what we have restricted, what we have refused, and why.

If we later lift a restriction we will tell you. Article 16(4) of the PDPL requires us to tell you that we have lifted it; telling you before we lift it rather than afterwards is our own undertaking and not something the Article requires, and we say which is which. As the platform stands, our register of requests has no concept of a restriction that is later lifted, so nothing in it would prompt the notification, and the undertaking depends on a person remembering.

21.10 Withdrawing consent. Where we rely on consent — the Clients section (13.11) and publication on the Roster (13.12) — write to us at the address in clause 2.5. You do not need to give a reason. We will remove the listing or the published entry within 5 business days and confirm when it is done. For the Clients section we keep an unpublished record that consent was given and withdrawn, so the company is not listed again by mistake; for the Roster the underlying record stays because we need it to appoint Arbitrators.

21.11 Revoking a case access link. If a notice reached a contact detail that is not yours, or that other people can reach, tell us at once. We will revoke the access link for that Case, issue a new one, and record the fact. Revoking a link does not stop the procedure and does not change any deadline.

21.12 Closing an account. Write to us and we will deactivate your account. We do not delete the account record itself, because Case records, the Journal and Roster entries refer to it. What survives is the record described in clause 20.8(h), and the address history described in clause 6.3.

21.13 How we give and receive notice. We contact you on the contact details we hold for you; for a party to a live Case, on the contact details on the Case file, and also on the case page. A notice from us is treated as given when we send it to one of those. You give us notice at the address in clause 2.5.

21.14 If we refuse. We will tell you what we have refused, why, and which provision we rely on, and we will tell you that you can complain to the Bureau.

22.1 There is automated processing on this platform that has legal effect, and we would rather describe it than deny it.

22.2 What is automated:

(a) Issue of the first notice. When the Stage 1 fee clears, the Cure Notice is generated and served automatically. No administrator reads the file first, and the check that the contract incorporates the Rules rests on the Claimant's declaration alone. This is the step with the greatest effect on a person who never chose to deal with us, and clause 3.4 says the same thing to that person.

(b) Deadlines. Periods under the Rules run and expire automatically, enforced by a job that runs every minute: the cure period, the election periods, the defence and reply periods, the objection period, the compliance period and the settlement confirmation period. Three expiries dispose of a Case with no human involvement at all: a 30-day window to commence arbitration and a 7-day window to elect after a disputed cure each close the Case, and a Claimant's silence for 48 hours after a settlement declaration is treated as confirmation and concludes the settlement.

(c) Effective service. Whether service has taken effect, and at what moment, is determined automatically from the transmission records, in accordance with the Rules. This is the determination with the greatest legal consequence on the platform: it founds a ratification application under Article 55, and it bears on a challenge under Article 53.

(d) Passing the Respondent by on expiry of the defence period. If no defence is filed in time, the Case moves automatically to the award stage and a Confirmation of No Statement of Defence is produced and served by machine. A defence filed late is still accepted, up to the moment the award issues, and whether to admit it is for the Arbitrator.

(e) Notice generation. The Cure Notice, the Request for Arbitration, the certificates of service and the invoices are produced automatically from the Case record.

(f) Payment recognition. A payment moves the Case forward automatically when the payment provider confirms it.

(g) Conflict screening. Before an Arbitrator is designated, the platform runs a narrow, mechanical check for a relationship between the proposed Arbitrator and the Claimant. The check decides nothing. An administrator designates, and may proceed over a flag only by recording a reason. The platform can also be configured to designate automatically from the Roster, subject to the same conflict screen; it is not so configured, and if that changes this clause changes with it, because the setting is a database value and not a property of the platform.

22.3 What is not automated. No decision about the merits of any dispute is automated. The Arbitrator is a human being who reads the file and writes the award, and every step that decides anything — accepting the appointment, issuing Procedural Order No. 1, deciding a settlement objection, terminating, and issuing the award — is available only to the Arbitrator. We do not profile, score, rank or rate any person. We use no automated system to assess anyone's credibility, risk or character. There is no artificial intelligence in the decision path. A translation tool is available to an Arbitrator as a drafting aid; nothing it produces reaches a document unless the Arbitrator writes it there.

22.4 Your right to a human. You may require a person to look at any automated step in clause 22.2, to hear your point of view, and to reconsider it. Article 18 of the PDPL gives you that right, and for a Respondent it is unqualified: the three cases in which the PDPL removes the right to object to an automated decision are agreement in a contract with us, a requirement of another law, and your prior consent, and none of them applies to you. Article 18(4) separately requires us to involve a person in reviewing an automated decision when you ask, with no exception at all.

How to use it: write to us at the address in clause 2.5, or say so on your case page. Before an Arbitrator is appointed, an administrator will consider it and tell you the outcome and the reasons. Once an Arbitrator is appointed, it is for the Arbitrator, and we will put your statement before them. On request we will give you the underlying transmission and provider records that an automated determination of service relied on.

There is one limit, and we would rather tell you now than refuse you later. Where a period has expired and the Case has closed automatically under clause 22.2(b), the platform has no route that reopens it: that closed state is final in the platform's own machinery, and no extension can be applied to a Case in it. So for those three expiries a person can be asked to look, and will, and will record what you say on the Case file and tell you the outcome and the reasons — but the platform gives them nothing to act with. Whether that route is built is a decision for us and it has not been taken. What is not affected is the Arbitration Law, which gives you rights before the Dubai Court of Appeal that nothing in this policy or the Rules can take away.

22.5 Deadlines can be changed, but only by us or by the Arbitrator. An administrator can change a deadline running before an Arbitrator is appointed. An Arbitrator or an administrator can change one running after appointment. Every change requires a recorded reason, produces a Notice of Extension, and is notified to both parties. There is no route by which a party can ask for more time: Section 5.2 of the Rules says the cure period may be extended for fairness or manifest impracticability, and as the platform stands that depends on somebody inside it acting of their own motion. If you need more time, write to us at the address in clause 2.5 or say so on your case page, and we will put it in front of the person who can decide it. Clause 3.10 says the same thing at the front, to the reader who needs it most.

22.6 Our position on the timetable. The periods themselves come from the Rules that the parties incorporated into their own contract. They cannot be switched off for one party without changing the procedure for both. If you think the procedure has gone wrong, you can raise it with the Arbitrator, and the Arbitration Law gives you rights before the Dubai Court of Appeal that nothing in this policy or the Rules can take away.

23.1 Article 20 of the PDPL requires us to apply the highest standard of information security appropriate to the risk, in accordance with best international practice, and names four things it must include: encryption and pseudonymisation of Personal Data; measures keeping processing confidential, safe, accurate and resilient; measures allowing Personal Data to be retrieved and reached again after a failure; and measures for testing and evaluating how well all of it works. This clause is what we do, and it says where we fall short.

23.2 Pseudonymisation. Identity document numbers are masked before they are stored on a party record, and there is no column on that record that holds the full number. A password is stored only as a one-way hash, a sign-in link and a one-time code only as digests, and the address a password was tried against only as a keyed digest. Website measurement identifies a reader by a keyed value and not by an address (clause 27.2(a)).

23.3 Files are held in private storage with public access disabled. There is no permanent link to any file. A download link you request is read-only and expires within 15 minutes, and no link can be made to last more than an hour. Where a document is delivered by WhatsApp, the link the messaging provider fetches it from is read-only and valid for 30 minutes, and during those 30 minutes it needs no password — clause 18.3. That is the one exception to the rule that a file of ours cannot be read from the public internet, and we state it rather than claiming the rule without it.

23.4 A Respondent can only see documents served on them. A request for anything else returns "not found", not "forbidden".

23.5 An Arbitrator can only see the Case they were appointed to, checked against their own Roster record on every request.

23.6 A signed-in Claimant, Arbitrator or administrator cannot act through the Respondent's door, and the reverse is true.

23.7 Credentials. Passwords are stored as one-way cryptographic hashes with a minimum length of 8 characters. Sign-in links and one-time codes are stored as digests and are single use. There is no lockout, because locking an account under attack locks out its owner; instead, repeated attempts are slowed. Rate limits apply to every sign-in path. Sessions are short-lived, revocable by us, and bound to a single device where the browser supplies one.

23.8 Anti-enumeration. Requests that would reveal whether an account, a Case or a document exists are answered identically whether it exists or not, and take the same time to answer. This is deliberate: our account holders are businesses in or about to be in a dispute, and a varying answer would name them.

23.9 Internal access. Access to case content inside PLM is limited to people holding an administrator role, and a separate finance role exists for people who need payment records and not case content. Beyond those roles there is no further separation, we have no documented need-to-know limitation, and an administrator's act on a Case is recorded in the Journal while an administrator merely reading a Case is not. We would rather state that than describe a control we do not have. We are also required by Article 7(4) of the PDPL to keep a record of who is authorised to reach Personal Data, which is a second reason to fix it.

23.10 Transport and the browser. The site is served over HTTPS with strict transport security. Styles and fonts load only from our own origin. Scripts load only from our own origin, with one exception: on the public information pages, and only after you have agreed, the Google Analytics script described in clause 27.2 is loaded from Google. It is never loaded on any page carrying a Case credential, and those pages continue to be served with no-store, no-referrer and no-index headers.

23.11 Data minimisation in logs. The automatic filter in clause 11.6, with the limits stated in clause 11.7.

23.12 Integrity. Every document carries a digital fingerprint of its content and of its PDF. Every evidence file is fingerprinted on upload, and that fingerprint is committed to the Journal at that moment, which fixes the file in time. A court bundle will not be certified if a stored fingerprint no longer matches the bytes.

23.13 Backups and getting your data back after a failure. The database is backed up nightly and has a point-in-time recovery window, and a nightly dump is written to a separate account. Geo-redundant database backup is not enabled, so the loss of the region would be the loss of the database. We have recorded one restore drill. Article 20(1)(c) requires us to be able to reach Personal Data again after a failure, and that duty is owed whatever this clause says, so we state the position rather than a reassurance.

23.14 Testing, and the impact assessment. Article 20(1)(d) requires us to test and evaluate how well these measures work, on a recurring basis, and Article 21 requires an assessment before processing that uses modern technology and poses a high risk. We have not documented either. Both are being put in place, and the assessment will cover the Journal and the automatic issue of the first notice specifically.

23.15 The record of processing. Article 7(4) of the PDPL requires us to keep a record of our processing activities, containing our own and the Data Protection Officer's details, the categories of Personal Data, the people authorised to reach it, the times, limits and scope of processing, the mechanism for erasing and changing it, the purposes, any cross-border movement, and the security measures, and to give it to the Bureau when asked. Parts B, C and D of this policy are most of it. The record itself does not exist yet, and the part of it that lists who may reach Personal Data is not something we would publish in any event.

24.1 If a breach of Personal Data occurs that would prejudice its privacy, confidentiality or security, we will notify the Bureau at the time we become aware of it, as Article 9 of the PDPL requires, and we will notify you where the PDPL requires it. The PDPL leaves the period and the manner to the Executive Regulations, and no period is prescribed, so we state the trigger and not a number.

24.2 A notification to the Bureau must describe the nature, form and cause of the breach and the approximate number of records, give the Data Protection Officer's details, state the likely effects, set out the corrective measures taken or proposed, and enclose the supporting documents. Those are five of the six things Article 9(1) lists. The sixth is anything further the Bureau requires, which we cannot state in advance.

24.3 A notification to you will describe, so far as we know it: what happened, what data was affected, the likely consequences, what we have done, and what you can do.

24.4 We do not keep a standing register of breaches, and we say so rather than describe one. Earlier versions of this policy said that we kept a record of every breach and that it was built to the list in Article 9(1). That is not true: there is no breach register anywhere in the platform — no table, no module, no route — and we would rather correct it here than leave a published control that does not exist. Until a register is built, a breach is recorded on the Case record and in our operational record and reported under clause 24.1. Two incidents are the most likely here and we have them specifically in mind: a served document reaching the wrong recipient, and the exposure of a case access link, which for a Respondent is the whole of their access control.

24.5 Article 9(3) of the PDPL requires a Processor to tell us as soon as it becomes aware of a breach. That duty is imposed by the law and does not depend on our contract with anyone. Whether the contract with each recipient named in clause 17 also carries the term is something we are checking, and we will not assert that it does until we have.

25.1 If you open a Case, the Personal Data you give us about the other party remains data for which you are answerable. You need your own lawful basis to disclose it to us.

25.2 You must not give us more than the procedure needs. In particular, do not upload the other party's identity document: we do not require one, and it will go into a court bundle whole if the Case reaches that point.

25.3 You are entitled to supply only material you may lawfully supply, and only material that contains no Personal Data of anyone other than the parties to the dispute and the people the procedure requires to be named. We do not presently take that confirmation at the upload control, and we intend to.

25.4 You should tell your authorised signatory that we hold their identity document as described in clause 6.6, that it is held indefinitely because no rule reaches it, and that it may go into a court bundle.

25.5 You should name a file so that its name does not disclose somebody's name — clause 8.3.

25.6 What enforces the five paragraphs above, which is presently nothing. They are what we ask, and not terms you have accepted. No Terms of Use is in force and the platform asks nobody to accept one (clause 29.7), and the declarations a Claimant signs when filing do not contain them: the only processing consent recorded on filing is limited to the purposes of the arbitration and any subsequent ratification or enforcement. There is also no check at the upload control. So until these paragraphs are carried into an instrument a Claimant accepts, or enforced at the control, nothing on the platform stops a Claimant doing the opposite. A Respondent should read clause 25.2 as our position and not as a protection.

26.1 UORA is a service for businesses and their customers. It is not designed for, and is not directed at, children.

26.2 We do not verify anyone's age. Account creation asks for an email address and nothing more, so our records cannot tell us whether an account holder is an adult, and we do not verify a Respondent's age. A Respondent is named by somebody else and never registers, so we have no age signal about them at any point.

26.3 If we are told, or come to believe, that a Respondent is under 18, we will suspend service on them, tell the Claimant, refer the matter to an administrator, and not issue a further notice without the direction of the Arbitrator where one has been appointed. If the Claimant cannot satisfy us that the contract is enforceable against that person, we will not continue to process their data on that basis. We do not pass that question to the Claimant or the Arbitrator to answer for us: we are the Controller, and at the Cure Notice stage no tribunal exists.

26.4 The PDPL contains no provision about children's data. Federal Law No. 3 of 2016 on Child Rights bears on this, and Federal Decree-Law No. 26 of 2025 on child digital safety is reported to have come into force on 1 January 2026 with a grace period to 1 January 2027, which is close enough to matter for this release. We have not read its text and we do not state its requirements.

26.5 If you believe we hold personal data about a child, tell us at the address in clause 2.5 and we will look at it promptly.

27.1 The parts of this website you use to run a case set no cookies. The public information pages ask, once, whether you agree to the measurement described in clause 27.2; until you agree, nothing described there is loaded and no cookie is set. You may change that answer at any time from the link in the page footer, and withdrawing it is as easy as giving it.

27.2 Measurement, and its two halves. There is no advertising pixel on any page and no tag manager. Fonts are served from our own domain.

(a) Our own count. Every page of the public site reports to us alone that it was opened, which control was pressed, the shape of the address (never the address itself, which on some pages is a credential), the site that linked you here (its name only, never the page or its query string), and a device class. It sets no cookie and stores nothing on your device beyond a per-tab identifier that is discarded when you close the tab. No network address and no browser identification string is stored on these records at all. To count you once a day without keeping your address, we combine your address with a secret we hold and the calendar date, and keep the result; it changes every midnight, and nobody without that secret can turn it back into an address or link two days of your reading together. We hold the secret, so we do not describe the value as anonymous: it is pseudonymised, and the honest statement is that it identifies nobody to anyone but us. If your browser sends a Do Not Track or Global Privacy Control signal, none of this is recorded at all. This runs without asking. Records are deleted after 120 days.

(b) Google Analytics, only if you agree. On the public information pages only, and only after you have agreed under clause 27.1, we load Google Analytics 4. Google then receives your IP address and sets the cookies named in clause 27.3. Google is named in clause 17.1(l) and the transfer abroad is covered by clause 18.8. We treat Google as our processor for this, and clause 17.1(l) says that whether that is the right characterisation for all of it is something we are confirming rather than asserting. It is never loaded on a page that carries a Case credential.

What it records there: that a page was opened, how far down it you scrolled, which links out of the site you followed, anything you typed into the site's own search, that you began or completed a form, any video you played, any file you downloaded, and the ordinary device, browser, language and approximate location characteristics every browser sends. Google keeps it for the period set on our measurement property. That period is 14 months, for event data and for user data alike; the provider’s own default is 2 months and we raised it deliberately.

What it does not record. We do not enable Google's advertising features, so nothing here builds an advertising profile of you and no advertising network receives it. We send Google no identifier of ours and nothing that names you. We do not send Google the address of the page you are on: we send the shape of it, with the query string and the fragment removed whole, because on some pages the address is a credential — that control is real and it is the one that matters most.

Two things we do not do, which earlier versions of this policy, the dialogue described in clause 27.1 and the currently published version of this page all say we do. We do not strip email addresses, or the values of eighteen named query-string keys, out of the addresses, referrers and links that reach Google: no such filter exists anywhere in our website code, and the sentence describing one should never have been written. And we do not suppress what your browser reports to Google as the page that referred you, so where that referring address carries a query string, Google receives it whole. Both of those statements are live on our website today, and correcting them in the same release as this policy is one of the things that has to happen before this policy is published.

We also do not tell you that we instruct Google to anonymise your IP address: the setting we send for that belongs to an earlier version of the product and we cannot evidence what Google does with it.

(c) Our website host, named in clause 17.1(i), carries the traffic between your browser and our service and sees each request.

27.3 Your browser's own storage is used for these things:

(a) Your sign-in token, held in session storage, which is cleared when you close the tab. It is deliberately not held in longer-lived storage: a case file contains the identity documents and correspondence of two private parties, and a session should not outlive the browser tab. It is sent to us with each request, which is how you stay signed in.

(b) A summary of your session, in the same place.

(c) A random device identifier, in local storage. It is sent to us with each request and we store it against your session. It lets us keep you signed in on one device at a time and sign you out elsewhere if a credential is used somewhere else. It is a random value; it is not derived from your device and it does not identify your hardware.

(d) A language preference on the respondent page, and a marker recording that you have seen a notice in the console. These stay on your device.

(e) A per-tab identifier for the count described in clause 27.2(a), in session storage, discarded when you close the tab. It is random, it is not derived from your device, and it does not survive the visit.

(f) Your answer to the question in clause 27.1, in local storage, so that you are not asked again on every page. It outlives the tab deliberately: a choice you have already made should not have to be made again. It is kept only in your browser, so if you clear your browser's storage you will be asked again, and we hold no record on our side of the answer you gave.

(g) If, and only if, you agreed under clause 27.1: Google Analytics cookies named _ga and _ga_ followed by our property identifier. They expire after two years unless you withdraw your agreement, at which point we stop loading the script; you can delete them from your browser at any time.

27.4 We do not combine any of these into a profile, and we do not ask Google to. We do keep server-side records of requests, described in clause 11.6, and the download records described in clause 11.14.

28.1 If you are unhappy with how we have handled your data, or if you think anything in this policy is inaccurate, tell us at the address in clause 2.5. We will acknowledge within 5 business days and reply within 30 days. As with clause 21.4, those are our own periods and not statutory ones.

28.2 You may complain to the Bureau at any time, under Article 24 of the PDPL. You do not have to come to us first. The Bureau is the UAE Data Office, and it publishes its own contact details. The form a complaint must take, and the time within which it must be answered, are among the matters the Executive Regulations would settle, so until those are issued we cannot state a route or a deadline without inventing one.

28.3 Complaining to us or to the Bureau does not affect any right you have before a court, or any right you have in the arbitration itself.

29.1 We will change this policy when what we do changes. We will not change what we do and leave the policy behind.

29.2 As against a Respondent, this policy is a notice, not an agreement. Changing it does not change what may lawfully be done with a Respondent's data.

29.3 Every version carries a version number and an effective date. When we publish a new version we will:

(a) increase the version number;

(b) state the effective date and what changed, in the version history at clause 30;

(c) keep every previous version available on request, and, once the archive is built, at uora.ae/privacy/v[N]. We put it that way because the archive does not exist yet: there is no such address, no redirect to one, and nothing in our page builder that produces one. Building it is a small piece of work and it belongs in the same release as the first published version, but until it is done the reliable route is to ask us.

29.4 For a change that materially affects how we handle Personal Data — a new Service Provider that receives case data, a new transfer outside the UAE, a new purpose, or a longer retention period — we will publish the new version at least 14 days before it takes effect, and we will notify account holders by email.

29.5 A party to a live Case is notified of a material change on the contact details on the Case file and on the case page.

A change of carrier or of channel takes effect for every Case, including one that is already live. That is a property of how the platform is built rather than a choice we make case by case: the carriers are configuration read at the moment of sending, and the set of channels available for a party is recomputed on every dispatch from our settings and the contact details on file — clause 14.11. Earlier versions of this policy undertook that no new Service Provider receiving a party's contact details, and no new channel, would be added to a Case already live. The platform cannot keep that undertaking. The mechanism exists for the Rules, which are pinned to a Case at opening and stay pinned, and there is no equivalent for carriers or channels. We have withdrawn the undertaking rather than publish one we cannot honour. What we will do instead is notify a party to a live Case, on the contact details on the Case file and on the case page, before such a change takes effect.

29.6 A change to this policy does not change the Rules, and cannot. The Rules are incorporated into the parties' own contract by version and date, each published version is immutable, and a Case is governed by the version its contract names.

29.7 Nothing on this platform records anyone's acceptance of this policy or of a Terms of Use. No Terms of Use is in force, and the platform asks nobody to accept one. This policy therefore takes effect as a notice and not as a term of any agreement, and clause 13.5 does not rest on a Terms of Use.

29.8 The SMS notice published as part of version 1.0, which this version withdraws. One section of version 1.0 of this policy was published and is in force as a separate instrument at its own version: the section covering text messages. It says two things that are wrong about this platform, and we would rather withdraw them expressly than let a new version quietly sit beside them.

It states a lawful basis of "the performance of the arbitration agreement between the parties and our legitimate interest in keeping an accurate record of it". The PDPL has no legitimate-interests basis at all (clause 13.1), and a Respondent is party to no contract with us (clause 13.4), so neither limb is available. And it undertakes that a reply of STOP to any message will stop further messages. No text message is sent by this platform at all, and nothing in it reads an inbound text message, so a reply of STOP would reach nobody (clause 14.10).

On the effective date of this policy that section is withdrawn and replaced by clauses 8.9, 11.2, 14.10 and 20.8(j), which state the position accurately. The published page carrying it must be withdrawn in the same release.

30.1 Version 1.0 — 17 September 2026. Most of it was never published. One part of it was, and still is in force: the section covering text messages, published as a separate instrument at version 1.0, which clause 29.8 withdraws and replaces. Earlier versions of this policy described version 1.0 as a first draft that was not published, which was wrong about that section.

30.2 Version 2.0 — 28 September 2026 — rewritten against a full re-examination of the platform. The material changes from version 1.0: the automatic issue of the first notice is stated in the indicative in clauses 3.4 and 22.2(a) instead of being left blank; a right to require human review is stated at clause 22.4 as an unqualified right for a Respondent, together with the one expiry a person cannot undo; the pre-processing information the PDPL requires is given at clauses 3.13 to 3.15; a Respondent is told at clause 3.10 how deadlines run and how to ask for more time; the primary email carrier is correctly identified as being outside the UAE and as carrying the served documents themselves (clause 17.1(c)), reversing what version 1.0 said; an accounting provider, a mail-forwarding provider and the review platforms are added as recipients and as transfers; the Assignee is named (clause 16.3); the operator alerts are disclosed as live rather than dormant (clause 16.9); the retained tax invoice is correctly described as replacing an erased party's name rather than keeping it, and as keeping the paying party's own details (clause 20.7(b)); the categories with no retention rule go from three to seven, and the absence of any removal route for them is stated (clause 20.9); three holdings are disclosed for the first time — invitations (clause 6.8), the cash-payment permission (clause 9.2) and download records (clause 11.14); the statement that we keep a register of breaches is withdrawn (clause 24.4) and the Article 9(1) count corrected (clause 24.2); the statement that eighteen query-string keys are stripped before anything reaches Google is withdrawn (clause 27.2(b)); Article 41(5) is no longer cited as the necessity for a party's nationality (clause 12.4) and Article 10 is no longer cited as requiring a declaration about a criminal record (clause 12.2(c)); the Article 4(10) supporting basis for the case file is withdrawn (clause 13.2); the long verification code is disclosed as not printed on any document (clause 19.3(b)); the settlement fee payable by a Respondent is disclosed at clause 3.11; the basis for security processing moves from Article 4(9) to Article 4(10); sensitive data is stated to need no further condition under Article 4 (clause 12.6); the undertaking that no new provider or channel would be added to a live Case is withdrawn as one the platform cannot keep (clause 29.5); the SMS section of version 1.0 is withdrawn (clause 29.8); and the clauses that promised an upload warning and an upload confirmation are redrafted to say that neither exists.