Schedule 1 — Mandate Summary: When Your Money Leaves Your Pocket

1. YOU ARE IN THE STORE. The App confirms your physical presence at the Merchant’s premises through the automated Proximity Check-In (Article 9.2). No Payment Request can be initiated unless you are physically present.

2. THE MERCHANT SEES YOUR FACE AND INITIALS. Your Facial Authentication Profile (your photograph and initials, e.g. “J.D.”) is displayed on the Merchant Terminal. The Merchant’s employee visually matches you to your profile and selects your account (Article 11.3.2(c)–(d)).

3. THE TERMINAL CALLS OUT YOUR INITIALS AND THE AMOUNT. Before the transaction amount is finalised, the Merchant Terminal audibly announces or visually displays your initials and the amount you are about to be billed. This call-out is recorded for evidence (Article 11.3.2(j)).

4. YOU DO NOT SAY “STOP.” By remaining at the billing counter and not objecting, withdrawing, or communicating dissent after hearing or seeing the call-out, you confirm the amount is correct and consent to the Payment Request being initiated (Article 11.2(d) and Article 11.3.2(j)).

5. YOU HAVE UP TO 12 HOURS TO CHANGE YOUR MIND. After the transaction is initiated, a Critical Transaction Alert is sent to your device and a hold is placed on the amount. You have between five (5) and twelve (12) hours — the Grace Period — to dispute the transaction through the App. If you do not dispute within this window, the transaction is settled and generally cannot be reversed (Article 12).

6. THE LOOKPAY INTEGRITY ENGINE WATCHES EVERY TRANSACTION. Every Payment Request is screened by the LookPay Integrity Engine. If a transaction deviates from your normal spending patterns (merchant type, location, amount, frequency), the mandate is suspended for THAT transaction ONLY and you will be prompted to provide fresh biometric authentication (passkey, fingerprint, or facial scan) before the payment can proceed (Article 11.6).

Part A — Introduction, Definitions, and Interpretation

Article 1 — The Master Agreement

1.1 Entirety and Integration. This Agreement, including its Preamble, all Articles, Schedule 1 (Mandate Summary), the Exhibits, the Privacy Policy (as updated and published at lookpay.app/privacy), and the Acceptable Use Policy, constitutes the complete and exclusive understanding between LookPay and the User with respect to the subject matter hereof. It supersedes and extinguishes all prior marketing materials, beta-testing understandings, oral representations, and preliminary communications. No addition to or modification of this Agreement shall be effective unless explicitly published by LookPay in accordance with Article 32.

1.2 Non-Waiver of Rights. No failure or delay by LookPay to exercise any right, power, or remedy under this Agreement shall operate as a waiver thereof, nor shall any single or partial exercise preclude any further exercise. All rights and remedies of LookPay are cumulative and not exclusive of any rights or remedies provided by law.

1.3 Severability and Reformation. If any term, clause, or provision of this Agreement is held by a court or regulatory authority of competent jurisdiction to be invalid, void, or unenforceable, that provision shall be enforced to the maximum extent permissible and, if entirely unenforceable, shall be severed from the Agreement. The remaining provisions shall continue in full force and effect, and the parties shall negotiate in good faith to replace the severed provision with a valid one that most closely reflects the original commercial intent.

Article 2 — Definitions and Rules of Construction

2.1 Capitalised Definitions. In this Agreement, the following words and phrases shall have the meanings set out below unless the context requires otherwise:

“App” — The LookPay mobile application software (including any updates, patches, or replacements) provided by LookPay for use on compatible mobile devices.

“Authorised Regulated Partner” — The Electronic Money Institution (EMI) or Payment Institution (PI) authorised and regulated in the European Economic Area (presently XXXX Group or any successor) that issues the Electronic Money (E-Money), provides the underlying stored-value accounts, and executes all settlement and fund-safeguarding operations.

“Conditions Precedent” — Each of the mandatory, objectively verifiable conditions enumerated in Article 11.3.2 that must be concurrently satisfied before a Merchant-Initiated Transaction (MIT) — in the form of a Payment Request — may be validly initiated by a Merchant (as payee) under the Standing Payment Mandate and routed by LookPay (as technical intermediary) to the Authorised Regulated Partner (as the payment service provider) for execution. No single Condition Precedent is sufficient in isolation; the failure of any one Condition Precedent renders the Payment Request invalid and incapable of being executed by the Authorised Regulated Partner.

“Critical Transaction Alert” — The push notification, in-app message, or equivalent electronic communication dispatched by the LookPay backend infrastructure to the User's device when a Merchant has initiated a transaction on the User's profile.

“E-Money” — Electronically stored monetary value, as defined in the European Communities (Electronic Money) Regulations 2011 (S.I. No. 183 of 2011), representing a claim on the Authorised Regulated Partner, issued on receipt of funds for the purpose of making payment transactions.

“Facial Authentication Profile” — The digital photograph and associated initials (comprising the User's first initial and surname initial, formatted as e.g. "J.D.") uploaded by the User for the sole purpose of enabling Merchant-side visual verification through the Merchant Terminal.

“Force Majeure Event” — Any act, event, omission, or circumstance beyond LookPay's reasonable control, including but not limited to those specified in Article 29.

“Grace Period” or “Revocation Grace Period” — The strictly defined window, notified to the User within the App on a per-transaction basis, during which authorised funds are held pending and the User may initiate a formal dispute prior to irreversible settlement. This period shall be no less than five (5) hours and no more than twelve (12) hours from the moment the Critical Transaction Alert is dispatched.

“LookPay E-Wallet” — The digital ledger interface within the App that displays the balance of E-Money issued to the User by the Authorised Regulated Partner.

“Merchant” — A third-party commercial entity, retailer, or service provider (acting as payee in respect of each payment transaction) that has entered into a separate agreement with LookPay to accept payments via the LookPay infrastructure.

“Merchant Terminal” — The hardware device (tablet, point-of-sale unit, or equivalent) provided or authorised by LookPay to a Merchant, on which the Facial Authentication Profiles of Users present in the premises are rendered and through which transaction amounts are entered and Payment Requests initiated.

“Payee” — The Merchant, being the intended recipient of the payment proceeds in respect of each payment transaction executed under this Agreement.

“Payment Request” — The instruction initiated by a Merchant (as payee) under the Standing Payment Mandate, requesting the execution of a debit from the User's E-Money account held with the Authorised Regulated Partner, routed by LookPay to the Authorised Regulated Partner for execution following satisfaction of all Conditions Precedent.

“Proximity Check-In” — The automated, technology-agnostic process by which the App detects the User's physical presence within a defined spatial perimeter around a participating Merchant's premises, using device permissions lawfully granted by the User.

“Regulatory Authority” — The Central Bank of Ireland, the Financial Conduct Authority (where applicable), the European Banking Authority, the Data Protection Commission, or any other competent supervisory body.

“Services” — The App, the Proximity Check-In mechanism, the Merchant Terminal interface, the Critical Transaction Alert system, the Grace Period dispute facility, and all related backend support, collectively referred to as the "LookPay proximity checkout ecosystem."

“Standing Payment Mandate” — The advance, informed, and explicit conditional authorisation provided by the User to the Authorised Regulated Partner (via the LookPay platform) authorising the Authorised Regulated Partner to execute debits from the User's E-Money account upon receipt of valid Payment Requests initiated by participating Merchants (as payees) and routed to the Authorised Regulated Partner by LookPay following the satisfaction of all Conditions Precedent. The Standing Payment Mandate is executed (signed) by the User during the Account creation process through the User's explicit biometric confirmation (fingerprint or facial scan), constituting Strong Customer Authentication within the meaning of Article 4(30) of PSD2 and Commission Delegated Regulation (EU) 2018/389. The SCA event at mandate execution applies three independent authentication elements drawn from all three categories required by PSD2: (A) possession — the User's registered device, bound to the Account through device hardware identifiers and cryptographic session tokens; (B) inherence — the biometric confirmation (fingerprint or facial scan) provided by the User through the App; and (C) knowledge — the User's Account password or PIN entered during the initial login session immediately preceding the mandate execution. The application of all three SCA categories exceeds the minimum PSD2 requirement of at least two independent elements from two or more categories. At the time of execution, the User is required to read and acknowledge the entirety of this Agreement in full, and thereafter provide an affirmative biometric confirmation through the App, which simultaneously: (i) constitutes the User's binding electronic signature of the Standing Payment Mandate; (ii) satisfies the SCA requirement for the establishment of the mandate in accordance with PSD2 and the European Union (Payment Services) Regulations 2018; and (iii) authorises both LookPay (as Technical Service Provider and routing layer) and the Authorised Regulated Partner (as the licensed payment service provider lawfully entitled to rely upon this mandate) to act upon the Standing Payment Mandate for the execution of debits from the User's E-Money account upon satisfaction of all Conditions Precedent. The Standing Payment Mandate is reaffirmed (but not re-executed) by each subsequent top-up transaction, each of which is independently authenticated by the Authorised Regulated Partner's own SCA procedures applied to the underlying banking rail or funding source. The Standing Payment Mandate is subject to revocation by the User at any time by the means described in Article 11.2(g). In the event the User revokes the mandate, a new biometric SCA event shall be required to re-establish it. The Standing Payment Mandate is not a general, unrestricted, or plenary authority to debit the E-Wallet; it is a conditional, purpose-limited, and revocable standing authorisation that takes effect only when all Conditions Precedent are concurrently satisfied, at which point the Authorised Regulated Partner is instructed and authorised to execute the debit.

“Strong Customer Authentication (SCA)” — Has the meaning prescribed in Article 4(30) of Directive (EU) 2015/2366 (PSD2) and the European Union (Payment Services) Regulations 2018 (S.I. No. 6 of 2018).

“User Device” — The mobile telephone, tablet, or other hardware device on which the User has installed the App and which the User owns or lawfully controls.

2.2 Interpretation. (a) Headings and titles are for convenience only and shall not affect the construction of this Agreement. (b) Unless the context otherwise requires, words importing the singular include the plural and vice versa, and words importing a gender include every gender. (c) Any reference to a statute, statutory provision, or regulation includes any subordinate legislation, amendment, extension, or re-enactment thereof for the time being in force. (d) The word “including” shall be construed as “including without limitation”.

Part B — Regulatory Status, Funds Safeguarding, and E-Wallet Framework

Article 3 — LookPay’s Strict Role as a Technical Service Provider

3.1 PSD2 Exemption. The User explicitly acknowledges, stipulates, and agrees that LookPay Limited operates exclusively as a Technical Service Provider (TSP) within the meaning of Article 3(j) of Directive (EU) 2015/2366 (PSD2) and Regulation 2(1) of the European Union (Payment Services) Regulations 2018. LookPay provides the user interface, the spatial detection overlay, the Merchant Terminal software, and the notification infrastructure. LookPay is not a credit institution, is not an Electronic Money Institution, is not a Payment Institution, and does not provide payment services as defined by PSD2. LookPay does not, at any time, receive, hold, or control User funds.

3.2 Sole Liability of the Authorised Regulated Partner. All E-Money loaded into, held in, and transferred out of the LookPay E-Wallet is issued, safeguarded, and settled exclusively by the Authorised Regulated Partner, which is licensed and regulated by the competent authority in its home Member State. The utilisation of the E-Wallet constitutes a direct contractual relationship between the User and the Authorised Regulated Partner, governed by that partner’s terms and conditions. LookPay shall bear no liability for any act or omission of the Authorised Regulated Partner, including but not limited to fund-safeguarding failures, insolvency, platform unavailability, or regulatory breaches.

3.3 No Custodial Relationship. The User acknowledges that LookPay is not a fiduciary and does not act as a trustee, custodian, or escrow agent. The visual balance displayed in the App is purely a reflection of the ledger maintained by the Authorised Regulated Partner.

Article 4 — Issuance and Nature of Electronic Money

4.1 Issuance. Upon receipt of cleared funds by the Authorised Regulated Partner in accordance with the top-up methods made available in the App, the Authorised Regulated Partner shall issue E-Money at par value to the User’s E-Wallet. The E-Money is denominated in euro (€) or such other currency as may be supported.

4.2 No Deposit or Investment. The E-Money does not constitute a deposit within the meaning of the Irish Deposit Guarantee Scheme or the EU Deposit Guarantee Schemes Directive (2014/49/EU). No interest, yield, dividends, or other pecuniary benefit shall accrue on any balance held. The E-Money is not a financial instrument and is not covered by investor compensation schemes.

4.3 Right of Redemption. The User maintains an absolute, non-derogable right to redeem the outstanding balance of the E-Wallet at any time at par value, in accordance with Regulation 30 of the European Communities (Electronic Money) Regulations 2011. Redemption requests must be submitted through the App and will be settled by the Authorised Regulated Partner to a verified bank account held in the User’s identical legal name. A redemption may be delayed or refused only to the extent strictly necessary to comply with Anti-Money Laundering (AML) or Counter-Terrorist Financing (CTF) obligations.

Article 5 — Funding and Top-Up Mechanisms

5.1 Permitted Funding Sources. The User may top up the E-Wallet using (a) Payment Initiation Services (Open Banking) or (b) supported debit or credit card tokenisation. All card data, personal security credentials, and sensitive payment information are handled exclusively by the Authorised Regulated Partner in compliance with PCI-DSS. LookPay’s systems do not at any point store, process, or transmit unencrypted Primary Account Numbers (PANs) or CVV codes.

5.2 Top-Up Execution and SCA. Each top-up transaction constitutes a payment transaction initiated by the User and shall be subject to Strong Customer Authentication in accordance with PSD2. The Authorised Regulated Partner will apply SCA at the time of the top-up. Once the funds are credited to the E-Wallet, they are available to support Payment Requests initiated by Merchants (as payees) under the Standing Payment Mandate, as described in Part E.

5.3 Chargebacks and Reversals on Funding. Should a top-up be reversed by the User’s card issuer or bank due to a dispute or fraud claim, LookPay reserves the right, in coordination with the Authorised Regulated Partner, to immediately freeze the corresponding amount in the E-Wallet, suspend the account, and seek recovery of any shortfall. The User indemnifies LookPay against any losses arising from a reversed top-up.

Part C — Eligibility, Account Registration, and Customer Due Diligence

Article 6 — Eligibility and Representations

6.1 User Representations and Warranties. By creating an account, the User represents, warrants, and covenants that:

• the User is a natural person of at least eighteen (18) years of age (or the age of majority in their jurisdiction, if higher);
• the User possesses full legal capacity to enter into binding contracts;
• the User is not acting as an agent, nominee, or intermediary for any third party;
• the User has not been previously banned, suspended, or restricted from using LookPay;
• all information provided during registration and thereafter is true, accurate, current, and complete.

Article 7 — Account Creation and Security

7.1 Registration. To use the Services, the User must download the App and complete the registration process, which will include provision of a valid email address, a mobile telephone number, full legal name, date of birth, and residential address. The User must create a secure password and, where the device supports it, enable biometric login (fingerprint or facial recognition).

7.2 Device Binding and Single Session. The Account is intended for use on a single User Device at any given time. LookPay may, at its sole discretion, apply technical measures to associate an Account with a specific device hardware identifier to protect security. The User shall not attempt to circumvent such measures.

7.3 Account Responsibility. The User is solely and absolutely responsible for maintaining the confidentiality of all login credentials, passwords, and the physical security of the User Device. Any transaction or action taken through the User’s Account while the User Device is in the User’s possession (or prior to LookPay receiving formal notification of loss or theft) shall be conclusively deemed to have been authorised by the User.

7.4 Notification of Unauthorised Access. The User must immediately notify LookPay at security@lookpay.app upon discovering any actual or suspected unauthorised access, loss, theft, or compromise of the User Device or Account. LookPay shall take reasonable steps to block the Account, but the User shall bear all losses arising before such notification is confirmed, subject to applicable law.

Article 8 — Customer Due Diligence (KYC/AML/CTF)

8.1 Mandatory Verification. In compliance with the Criminal Justice (Money Laundering and Terrorist Financing) Acts 2010 to 2021 and the Central Bank of Ireland’s AML Guidelines, LookPay and/or the Authorised Regulated Partner are required to verify the User’s identity before the provision of any wallet functionality. Verification may include, without limitation:

• Government-issued photographic identification (passport, national identity card, driving licence).
• Proof of residential address (utility bill, bank statement, official correspondence) dated within the last three months.
• A real-time liveness check and biometric comparison.
• Declarations concerning Source of Funds (SoF) and Source of Wealth (SoW) where Enhanced Due Diligence is triggered.

8.2 Ongoing Monitoring. LookPay and the Authorised Regulated Partner employ algorithmic risk-scoring and may conduct periodic reviews. The User agrees to provide any additional information or documentation requested without delay. Failure to comply with a CDD request within the timeframe specified shall result in immediate suspension of the Account and the E-Wallet until the matter is resolved, and may lead to permanent termination.

8.3 Politically Exposed Persons (PEPs) and Sanctions. (a) The User represents that they are not a Politically Exposed Person (PEP), nor a family member or close associate of a PEP, unless disclosed and approved in writing. (b) The User warrants that they are not located in, ordinarily resident in, or a national of a jurisdiction subject to comprehensive sanctions by the European Union, United Nations, or the Irish Department of Finance. (c) The User confirms they are not listed on any sanctions list, including the EU Consolidated List, the UK Sanctions List, or the US OFAC SDN List. (d) If the User becomes a PEP or is designated on a sanctions list during the term of this Agreement, the User must immediately notify LookPay. LookPay reserves the right to terminate the Account forthwith.

8.4 Suspicious Activity Reporting. LookPay and the Authorised Regulated Partner are legally obliged to file Suspicious Transaction Reports (STRs) with the Garda National Economic Crime Bureau (GNECB) and/or the relevant Financial Intelligence Unit (FIU) where money laundering or terrorist financing is suspected. The User acknowledges that, where an STR is made, LookPay is prohibited from informing the User of the report and may suspend all activity without prior notice. No liability shall attach to LookPay for any loss suffered as a result of such suspension.

Part D — The Proximity Checkout Ecosystem — Operational Description

Article 9 — Spatial Presence Detection and Terminal Synchronisation

9.1 Grant of Permissions. For the proximity checkout features to function, the User must grant the App the following operating system permissions: (a) Location Services: set to “Always” or “While Using the App”, to enable background detection of the User’s proximity to participating Merchants. (b) Wireless Communication Access (including, as applicable, Bluetooth and Wi-Fi): to establish a secure, localised link between the User Device and the Merchant Terminal. (c) Notifications: to receive Critical Transaction Alerts and service messages.

9.2 The Proximity Check-In. When the User physically enters a spatial zone around a LookPay-enabled Merchant (the perimeter of which is determined by LookPay in its sole discretion), the App executes an automated, silent Proximity Check-In. This process involves the local exchange of encrypted identifiers between the User Device and the Merchant Terminal, thereby confirming the User’s presence within the premises. No Payment Request or financial instruction is generated at this stage.

9.3 Profile Population. Upon a successful Proximity Check-In, the User’s Facial Authentication Profile (the photograph and initials, formatted as e.g. “J.D.”, on file) is automatically rendered on the screen of the Merchant Terminal. The User acknowledges that this terminal is located in a commercial environment and that the profile may be visible to the Merchant’s employees and, depending on screen placement, potentially to other customers present. By proceeding with the Proximity Checkout process, the User expressly consents to this display.

9.4 Anonymisation of Technical Identifiers. The User acknowledges that LookPay employs proprietary algorithms and data obfuscation techniques to protect the security of the Proximity Check-In. The User agrees not to attempt to reverse-engineer, intercept, or decode the handshake data, nor to use any tool to capture radio frequency signals or mimic the proximity protocol. Any such attempt shall be deemed a material breach and may result in immediate termination and notification to law enforcement.

Article 10 — Facial Authentication Profile and Biometric Display Consent

10.1 Upload Requirement. To participate in the proximity checkout ecosystem, the User must upload a recent, clear, full-face photograph and their initials (comprising the User’s first initial and surname initial, formatted as e.g. “J.D.”). The photograph must be a true and accurate depiction of the User as they appear at the time of transaction. No group photographs, avatars, AI-generated images, or photographs of other persons are permitted.

10.2 Biometric Public Display Consent [CRITICAL PROVISION]. The core functionality of the LookPay platform requires the display of the User’s Facial Authentication Profile on the Merchant Terminal. The User expressly consents to the display of their Facial Authentication Profile to participating Merchants and their staff as an essential and non-severable feature of the Service. This consent is fundamental to the operation of the Service; LookPay would not, and could not, provide the Service without it. The User’s consent under this Article 10.2 supplements, and is without prejudice to, the data protection rights and disclosures set out in LookPay’s Privacy Policy, available at https://lookpay.app/privacy, which the User is advised to read carefully before uploading any Facial Authentication Profile.

10.3 Accuracy Obligation. The User shall update the Facial Authentication Profile as necessary to ensure it remains an accurate representation. LookPay bears no liability for failed transactions or incorrect identification arising from an outdated or misleading profile or inaccurate initials.

10.4 Consent to Audio Recording and CCTV for Dispute Resolution [CRITICAL PROVISION]. The User expressly acknowledges, agrees, and consents to the following recording and surveillance activities as an integral part of the LookPay proximity checkout ecosystem:

(a) Audio Recording at the Merchant Terminal. When the User is present at a Merchant’s billing counter and a transaction is in progress under the Standing Payment Mandate, the Merchant Terminal shall record the audio of the initials and amount call-out described in Article 11.3.2(j). Where the call-out is generated by the Merchant Terminal’s text-to-speech functionality, the audio recording logs (including the timestamped TTS output, exact text rendered, and voice synthesis parameters) shall be captured and preserved. Where the call-out is spoken aloud by the Merchant’s employee, the ambient audio recording captured by the Merchant Terminal’s microphone shall be captured and preserved. The User consents to the capture and preservation of this audio recording for the purposes of: (i) creating an immutable audit trail of the transaction initiation; (ii) establishing Dynamic Linking between the specific transaction amount, the User’s identity, and the User’s contextual consent in accordance with PSD2; (iii) resolving any dispute arising from the transaction, including disputes concerning the amount billed, the identity of the person at the billing counter, or the validity of the User’s consent; and (iv) providing evidence in any legal, regulatory, or ombudsman proceeding arising from or connected to the transaction.

(b) CCTV Recording on Merchant Premises. The User acknowledges that participating Merchants may operate CCTV surveillance systems on their premises as part of their own security and loss-prevention operations, and that such CCTV systems may capture the User’s image, movements, and interactions at the billing counter during a transaction. The User consents to the capture of their image by Merchant CCTV systems and to the disclosure of CCTV footage by the Merchant to LookPay in connection with: (i) an abuse report, disputed transaction, or suspected fraudulent transaction involving the User’s Account; (ii) any investigation conducted by LookPay under this Agreement, including investigations into Merchant misconduct under Article 11.8; and (iii) any legal, regulatory, or ombudsman proceeding arising from or connected to a transaction. Time Limitation on CCTV Requests. LookPay’s right to request CCTV footage from a Merchant in connection with a particular dispute or investigation shall be limited to a period of thirty (30) calendar days from the date of the transaction that is the subject of the dispute or investigation. Where CCTV footage is not received by LookPay within this period, or where the Merchant does not operate CCTV systems or has not retained the relevant footage, LookPay shall be entitled to resolve the dispute based on the Server Records then available in its possession, and the absence of CCTV footage shall not be construed as evidence in the User’s favour nor shall it give rise to any liability on the part of LookPay.

(c) No Expectation of Privacy at the Billing Counter. By participating in the LookPay proximity checkout ecosystem and entering a Merchant’s premises for the purpose of conducting a transaction, the User acknowledges that they have no reasonable expectation of privacy in respect of their visual image, movements, or audible communications at the billing counter during the transaction process. The User’s consent under this Article 10.4 is given freely, voluntarily, and with full knowledge that audio recordings and CCTV footage may be used as evidence against the User in a dispute, investigation, or proceeding, including where such evidence contradicts the User’s own account of events. The User’s consent under this Article 10.4 may be withdrawn only by ceasing all use of the Services, deleting the App, and refraining from entering any Merchant premises for the purpose of conducting a transaction through the LookPay platform.

(d) GDPR Transparency and Privacy Policy Cross-Reference. The audio recording and CCTV processing activities described in this Article 10.4 involve the processing of personal data, including potentially biometric data and visual images, within the meaning of Regulation (EU) 2016/679 (the General Data Protection Regulation, “GDPR”). The lawful bases for such processing are: (i) the User’s explicit consent under Article 9(2)(a) of the GDPR, as given in this Article 10.4; and (ii) the legitimate interests of LookPay and the participating Merchants in fraud prevention, dispute resolution, and the establishment, exercise, or defence of legal claims under Article 6(1)(f) of the GDPR. Full details concerning the categories of personal data processed, the purposes and lawful bases of processing, the retention periods applicable to audio recordings and CCTV footage, the technical and organisational security measures employed, the categories of recipients (including the Authorised Regulated Partner and Merchants), and the User’s data subject rights (including the rights of access, erasure, restriction, and objection) are set out in LookPay’s Privacy Policy, available at https://lookpay.app/privacy, which the User is expressly directed to read in conjunction with this Article 10.4.

Article 11 — The Standing Payment Mandate, Consent Architecture, and Payment Request Framework

11.1 Transaction Flow and Role of Parties. Payment transactions under the LookPay proximity checkout ecosystem involve the coordinated participation of four distinct actors, each performing a defined role within the framework described in this Article 11:

(a) The Customer (Payer/User). The User establishes the Standing Payment Mandate — a conditional, revocable, purpose-limited standing authorisation — expressly authorising the Merchant (as payee) to initiate Merchant-Initiated Transactions (MITs) by submitting Payment Requests under the mandate, and authorising the Authorised Regulated Partner to execute corresponding debits from the User’s E-Money account upon receipt of such Payment Requests (routed by LookPay following the concurrent satisfaction of all Conditions Precedent). The User’s consent is provided through the distributed consent architecture described in Article 11.2. The User acknowledges and agrees that each individual transaction executed under this Agreement is a Merchant-Initiated Transaction: the Merchant (as payee) is the sole party that decides when and in what amount a Payment Request is initiated, and LookPay does not initiate, direct, or influence the timing or amount of any Payment Request.

(b) The Merchant (Payee — Initiator of Merchant-Initiated Transactions). The Merchant, acting as payee and the intended recipient of the payment proceeds, is the initiating party of each payment transaction under this Agreement. The Merchant initiates a Payment Request — constituting a Merchant-Initiated Transaction (MIT) within the meaning of the EBA Regulatory Technical Standards on SCA (Commission Delegated Regulation (EU) 2018/389) — under the User’s Standing Payment Mandate by entering the transaction amount on the Merchant Terminal following visual identification of the User. The Merchant does not execute the payment; it requests payment under the User’s pre-authorised mandate, and the debit is executed by the Authorised Regulated Partner as the User’s payment service provider. The Merchant’s role as initiator is fundamental to the regulatory classification of each transaction as an MIT, and the User expressly acknowledges that the Merchant — not LookPay — determines the timing, frequency, and amount of each Payment Request.

(c) LookPay (Technical Facilitator and Routing Layer — Not the Initiator). LookPay provides the technological infrastructure that facilitates the transaction. LookPay is not the initiator of any Payment Request. The Payment Request is initiated solely by the Merchant (as payee), and LookPay’s role is strictly limited to that of a technical routing intermediary. LookPay’s specific functions are: (i) validating the concurrent satisfaction of all Conditions Precedent set out in Article 11.3.2; (ii) dispatching the Critical Transaction Alert to the User as described in Article 11.7; (iii) operating the Grace Period dispute mechanism described in Article 12; and (iv) routing the validated Payment Request (which was initiated by the Merchant) to the Authorised Regulated Partner for execution as a technical pass-through. LookPay does not at any time execute the payment, hold funds, or make the decision to debit the User’s E-Money account. LookPay has no control over the timing, frequency, or amount of any Payment Request, all of which are determined solely by the Merchant as the initiating party.

(d) The Authorised Regulated Partner (XXXX — Payment Service Provider and Account Servicer). The Authorised Regulated Partner is the User’s payment service provider, holding the User’s E-Money account and acting as the account-servicing payment service provider (ASPSP). Upon receipt of a duly routed Payment Request from LookPay (being a Merchant-Initiated Transaction originated by the Merchant as payee, validated by LookPay, and passed through to the Authorised Regulated Partner for execution), the Authorised Regulated Partner executes the debit from the User’s E-Money account in accordance with the Standing Payment Mandate and transfers the funds to the Merchant’s account. The Authorised Regulated Partner is exclusively responsible for the execution of the payment transaction, including all obligations arising under PSD2 in respect of the authorisation, execution, and settlement of payment transactions.

The sequential operation of these four roles is as follows: the User gives the Standing Payment Mandate (a conditional, revocable authorisation for Merchant-Initiated Transactions); the Merchant (as payee) initiates a Merchant-Initiated Transaction by submitting a Payment Request under that mandate; LookPay validates the concurrent satisfaction of all Conditions Precedent and routes the validated Payment Request to the Authorised Regulated Partner; and the Authorised Regulated Partner executes the debit from the User’s E-Money account in its capacity as the User’s payment service provider. For the avoidance of doubt, the legal characterisation of each transaction is that of a Merchant-Initiated Transaction (MIT) executed under a standing payment mandate, where the Merchant is the payee and the initiating party, LookPay is a Technical Service Provider and routing intermediary, and the Authorised Regulated Partner is the payment service provider executing the debit.

11.2 Distributed Consent Architecture and Front-Loaded Strong Customer Authentication. The LookPay proximity checkout model implements a distributed consent architecture under which the User’s authorisation for each individual payment transaction is not conferred at a single moment at the point of sale, but is instead constructed from, and rests upon, a layered and cumulative sequence of affirmative acts undertaken by the User voluntarily and with full knowledge of their legal consequences. The User expressly acknowledges and agrees that no single act, standing alone, constitutes authorisation for a Payment Request; rather, it is the cumulative effect of the following five stages — each independently verifiable through Server Records — that establishes the legal basis for the Authorised Regulated Partner’s execution of each payment:

• (a)Stage One — Account Establishment and Biometric Execution of the Standing Payment Mandate (SCA Event). At the time of Account creation, the User undergoes a full Strong Customer Authentication procedure, comprising three independent authentication elements drawn from all three categories required by Article 97 of Directive (EU) 2015/2366 (PSD2) and Commission Delegated Regulation (EU) 2018/389 (the EBA Regulatory Technical Standards on SCA) — namely: (A) possession (something the User has), satisfied by the User's use of the registered and device-bound User Device, which is verified through device hardware identifiers, session tokens, and cryptographic handshake protocols that uniquely associate the device with the User's Account; (B) inherence (something the User is), satisfied by the biometric confirmation (fingerprint or facial scan) provided by the User at the point of mandate execution through the App; and (C) knowledge (something the User knows), satisfied by the User's Account password, PIN, or equivalent secret authentication credential which the User entered during the initial login session immediately preceding the mandate execution, thereby creating a contemporaneous and cryptographically linked chain of authentication events. The application of all three SCA categories — possession (the device), inherence (the biometric), and knowledge (the password) — exceeds the minimum PSD2 requirement of at least two independent elements from two or more categories and provides the highest available assurance level for the establishment of the Standing Payment Mandate. This SCA event establishes the User's identity to the regulatory standard required for the issuance of electronic money and creates the foundational trust relationship upon which all subsequent transactions under this Agreement depend. Immediately following successful identity verification, the User is presented with a dedicated, full-screen Mandate Activation Interface within the App — a discrete and clearly identified screen that: (i) displays a prominent summary of the Standing Payment Mandate and the Conditions Precedent under which future debits may be executed; (ii) requires the User to read and acknowledge the entirety of this Agreement by scrolling through the terms or confirming review of a linked copy; (iii) presents an explicit, unticked consent checkbox stating that the User understands and agrees that the Standing Payment Mandate authorises the Authorised Regulated Partner to debit the User's E-Money account upon satisfaction of all Conditions Precedent; and (iv) requires the User to provide an affirmative biometric confirmation (fingerprint or facial scan) constituting the User's binding electronic signature of the Standing Payment Mandate. The Mandate Activation Interface is designed as a deliberate, focused consent gate — separate and distinct from the general acceptance of this Agreement — such that the User cannot proceed to fund or use the E-Wallet without having passed through this specific interface and provided biometric SCA.
• (b)Stage Two — E-Wallet Funding via Authorised Regulated Partner (Independent Banking-Rail SCA). When the User first funds the LookPay E-Wallet, and on each subsequent top-up transaction thereafter, the User undergoes an independent SCA procedure applied by the Authorised Regulated Partner directly to the underlying funding source (debit or credit card, or Open Banking payment initiation service). This SCA procedure is applied by the Authorised Regulated Partner on its own banking rails and is separate from, and independent of, the LookPay distributed consent architecture described in this Article 11.2.
• (c)Stage Three — Proximity Enablement (Affirmative Operational Activation). By granting the operating system permissions described in Article 9.1 (comprising Location Services, Wireless Communication Access, and Notifications) and by thereafter entering the defined spatial perimeter of a participating Merchant's premises — an act that triggers the automated Proximity Check-In described in Article 9.2 — the User affirmatively and voluntarily activates the operational layer of the Standing Payment Mandate. This activation signals the User's presence within the LookPay ecosystem and their readiness to engage in proximity-based transactions. The User may withdraw this activation at any time by disabling the relevant permissions, deleting the App, or physically departing the Merchant's premises.
• (d)Stage Four — Transaction-Specific Conduct (Contextual Assent with Initials and Amount Verification). By approaching the billing counter, presenting specific goods or services for purchase, remaining physically present while the Merchant's employee scans or enters the items for purchase, and permitting the Merchant's employee to visually identify the User by reference to the displayed Facial Authentication Profile bearing the User's initials, the User provides transaction-specific, contextual assent to the Merchant's entry of the commercial sum attributable to the goods or services so presented. During the scanning or entry of items, the Merchant's employee and/or the Merchant Terminal (whether by audio announcement, visual display on the Merchant Terminal screen, or both) shall call out or display the User's initials (as appearing on the Facial Authentication Profile) and the running or final total amount that the User is about to be billed. This call-out or display serves as a real-time verification mechanism, enabling the User to confirm that: (i) the correct User identity (by initials) is associated with the transaction; and (ii) the amount being entered corresponds to the goods or services the User has presented. The User, by remaining at the billing counter and not objecting or withdrawing from the transaction following such announcement or display, is deemed to have confirmed the accuracy of the amount and the association of the transaction with their identity.
• (e)Stage Five — Post-Transaction Ratification (Grace Period Safeguard). Following the dispatch of the Critical Transaction Alert described in Article 11.7, the User is afforded a Revocation Grace Period of between five (5) and twelve (12) hours in accordance with Article 12. During this Grace Period, the User may review the transaction details — including the Merchant identity, location, and the precise amount — and, if the amount entered does not correspond to the goods or services presented, or if the Payment Request is otherwise erroneous or unauthorised, may initiate a formal dispute that immediately halts settlement and preserves the sequestered funds pending investigation.

Cumulative Effect. The User expressly acknowledges that the distributed consent architecture described in this Article 11.2, taken as a whole and with all five stages operating cumulatively, satisfies the requirement for the payer’s explicit consent to the execution of a payment transaction under Article 64(1) of PSD2 and Regulation 69 of the European Union (Payment Services) Regulations 2018 (S.I. No. 6 of 2018).

Revocation of the Standing Payment Mandate. The Standing Payment Mandate is revocable by the User at any time, without penalty and without the need to provide any reason. Revocation may be effected by any of the following means: (i) emptying the E-Wallet balance to zero by redemption or by spending; (ii) disabling the Location Services or Wireless Communication Access permissions granted under Article 9.1; (iii) deleting the App from all User Devices; or (iv) sending a written revocation request to support@lookpay.app. Upon revocation, no further Payment Requests may be initiated by any Merchant, and the Authorised Regulated Partner shall not execute any further debits under the revoked mandate. Re-Establishment of a Revoked Mandate. Where the User has revoked the Standing Payment Mandate and subsequently wishes to re-establish it, the User shall be required to undergo the full Stage One procedure described in Article 11.2(a) anew, including the requirement to read and acknowledge this Agreement and to provide a fresh biometric confirmation (fingerprint or facial scan) constituting a new SCA event. A top-up of the E-Wallet alone shall not suffice to re-establish a revoked mandate.

11.3 The Standing Payment Mandate — Conditions Precedent and Operational Framework.

11.3.1 Nature of the Mandate. The Standing Payment Mandate is a conditional, revocable, purpose-limited standing authorisation given by the User to the Authorised Regulated Partner (via the LookPay platform), under which the Merchant (as payee) is authorised to initiate Merchant-Initiated Transactions (MITs) by submitting Payment Requests. It is not, and shall not be construed as, a general, unrestricted, or plenary authority to debit the E-Wallet. It is not a blank cheque, an open-ended consent, a waiver of the User’s rights under PSD2, or a surrender of any statutory protection. The Standing Payment Mandate takes effect, and a Payment Request — being a Merchant-Initiated Transaction — becomes validly initiated by the Merchant (as payee) and capable of being executed by the Authorised Regulated Partner, if and only if each and every one of the Conditions Precedent enumerated in Article 11.3.2 is concurrently satisfied at the time the Merchant enters the transaction amount on the Merchant Terminal.

11.3.2 Enumerated Conditions Precedent. No Merchant-Initiated Transaction (MIT), in the form of a Payment Request, shall be validly initiated by a Merchant (as payee), and no Payment Request shall be routed by LookPay (as technical intermediary) to the Authorised Regulated Partner (as the payment service provider) for execution, unless and until ALL of the following Conditions Precedent are satisfied concurrently:

• (a)Merchant Onboarding and Standing Condition. The Merchant at whose premises the transaction is to occur: (i) has been duly onboarded by LookPay pursuant to a valid, subsisting Merchant agreement; (ii) has satisfactorily completed LookPay's due diligence procedures, including identity verification, AML/CTF screening, and sanctions screening; (iii) has not been suspended, restricted, or terminated from the LookPay platform; and (iv) is not, to LookPay's knowledge following reasonable enquiry, operating in material breach of any applicable law, regulation, or the terms of its Merchant agreement.
• (b)Physical Presence Condition. The User is physically present within the defined spatial perimeter of the Merchant's premises at the time the Payment Request is initiated, as confirmed by the automated Proximity Check-In protocol described in Article 9.2. The User shall not, and shall not attempt to, simulate, spoof, or falsify physical presence through GPS manipulation, VPNs configured to obscure or falsify location, Bluetooth relay attacks, signal amplification or replay, or any other means.
• (c)Profile Display Condition. The User's Facial Authentication Profile (comprising the User's photograph and initials, formatted as e.g. "J.D.", as uploaded and maintained in accordance with Article 10) is actively rendered, visible, and selectable on the screen of the Merchant Terminal at the time the Merchant initiates the Payment Request.
• (d)Visual Identification Condition. The Merchant's employee has, at the point of sale and before entering the transaction amount: (i) visually matched the physical appearance of the person standing at the billing counter to the Facial Authentication Profile (including the photograph and initials) displayed on the Merchant Terminal; (ii) verified that the initials displayed on the Merchant Terminal correspond to the identity of the person presenting goods or services for purchase; (iii) reasonably satisfied themselves, through such visual comparison and initials verification, that the person presenting goods or services for purchase is the Account holder whose profile is displayed; and (iv) selected the correct profile on the Merchant Terminal interface.
• (e)Transaction-Specific Conduct Condition. The User has: (i) approached the billing counter at the Merchant's premises while the Merchant Terminal is operational; (ii) presented specific goods or services for purchase; (iii) by such conduct, objectively indicated their assent to pay the commercial sum attributable to those goods or services; and (iv) not, prior to the Merchant's entry of the amount, communicated to the Merchant, to LookPay, or to the Authorised Regulated Partner any objection, withdrawal of consent, or intention not to proceed with the transaction.
• (f)Wallet Sufficiency Condition. The available balance of the User's E-Wallet at the moment of Payment Request initiation is equal to or greater than the amount entered by the Merchant. Where the available balance is insufficient to cover the full amount, the Payment Request shall be declined in its entirety and shall not be routed to the Authorised Regulated Partner for execution, and no partial hold shall be placed.
• (g)No Prior Revocation Condition. The User has not, prior to the Merchant's entry of the amount on the Merchant Terminal: (i) revoked the Standing Payment Mandate by any of the means described in Article 11.2(g); (ii) emptied the E-Wallet; (iii) disabled Location Services or Wireless Communication Access permissions; (iv) deleted the App; or (v) sent a written revocation, objection, or instruction to LookPay or to the Authorised Regulated Partner to suspend or terminate the Standing Payment Mandate.
• (h)No System Risk Flag Condition. LookPay's automated risk-scoring algorithms (which employ artificial intelligence and machine learning techniques for the detection of anomalous, fraudulent, or high-risk transaction patterns) have not identified the proposed Payment Request as requiring additional verification, manual review, or User confirmation before being routed to the Authorised Regulated Partner. Where a risk flag is raised, LookPay reserves the right to take any of the actions described in Article 11.6.
• (i)No Duress or Incapacity Condition. To LookPay's knowledge, and based on the information reasonably available to LookPay at the time of the transaction, the User is not acting under duress, coercion, undue influence, or incapacity, and the transaction does not exhibit indicia of financial abuse, exploitation of a vulnerable person, or any other circumstance that would vitiate consent under applicable law.
• (j)Initials and Amount Verification Condition. Prior to the entry of the final transaction amount on the Merchant Terminal and during the scanning or entry of items at the billing counter, the Merchant's employee, or the Merchant Terminal itself (whether by audio announcement, visual display on the Merchant Terminal screen, or both), shall have called out or displayed to the User: (i) the User's initials as recorded on the Facial Authentication Profile and displayed on the Merchant Terminal; and (ii) the total or running amount that the User is about to be billed for the goods or services presented. Audio Recording of Call-Out. During the call-out or display described in this Condition (j), the Merchant Terminal shall contemporaneously record the audio of the call-out — whether generated by the Merchant Terminal's text-to-speech functionality (in which case the audio recording logs, including the timestamped TTS output, the exact text rendered, and the voice synthesis parameters employed, shall be preserved as Server Records) or spoken aloud by the Merchant's employee (in which case the ambient audio recording captured by the Merchant Terminal's microphone shall be preserved as a Server Record). This audio recording serves to create an immutable, temporally-sequenced audit trail that: (A) captures the precise moment at which the User's initials and the transaction amount were communicated in the User's physical presence; (B) enables independent verification that the amount and initials announced match the amount entered and the profile selected on the Merchant Terminal; and (C) provides a contemporaneous record suitable for establishing Dynamic Linking between the specific transaction amount, the User's identity, and the User's contextual consent for the purposes of Article 97(2) of PSD2 and Commission Delegated Regulation (EU) 2018/389. The User, by remaining physically present at the billing counter and not objecting, withdrawing from the transaction, or otherwise communicating dissent following such call-out or display, is deemed to have confirmed: (A) that the User's identity (as represented by the displayed initials) is correctly associated with the transaction in progress; (B) that the amount being entered corresponds to the goods or services the User has selected and presented; and (C) that the User consents to the entry of that amount on the Merchant Terminal for the purpose of initiating a Payment Request under the Standing Payment Mandate.

11.3.3 Objective Verifiability. The User expressly acknowledges and agrees that the satisfaction or non-satisfaction of each Condition Precedent is objectively verifiable through the Server Records maintained by LookPay in the ordinary course of its business, as further described in Article 24B, including without limitation: Proximity Check-In event logs, Merchant Terminal event logs, Payment Request records, Facial Authentication Profile display logs, risk-scoring algorithm outputs, and User Account status records. The User agrees that the Server Records shall constitute prima facie evidence of the satisfaction of the Conditions Precedent for any given transaction.

11.3.4 Cumulative and Non-Severable. The Conditions Precedent are cumulative. The failure of any single Condition Precedent renders the Payment Request invalid and incapable of being executed by the Authorised Regulated Partner, regardless of the satisfaction of all other Conditions Precedent. The User acknowledges that the Conditions Precedent operate for the User’s protection as well as for LookPay’s, and that they collectively ensure — to the maximum extent technically and operationally feasible — that no Merchant-Initiated Transaction (MIT) can be routed to the Authorised Regulated Partner for execution without the User’s verified physical presence, the Merchant’s visual verification and initials confirmation, the User’s transactional conduct including real-time amount verification, sufficient wallet funds, and the absence of system-detected risk factors. The Conditions Precedent serve as the gatekeeping mechanism that validates each MIT before it is routed by LookPay to the Authorised Regulated Partner, ensuring that only Payment Requests that meet every enumerated condition proceed to execution.

11.4 Regulatory Classification of Transactions.

11.4.1 Acknowledgment of Novelty. The User acknowledges that the proximity checkout model implemented by LookPay combines several elements — including pre-funded e-money wallets, proximity-based identity verification, standing payment mandates, facial-identification-based Merchant verification, and delayed settlement with a post-transaction dispute window — in a configuration that is, to LookPay’s knowledge, novel in the European payments market.

11.4.2 Possible Regulatory Classifications. The Authorised Regulated Partner (XXXX), as the licensed payment service provider executing the debits from the User’s E-Money account, is exclusively responsible for determining the appropriate regulatory classification of transactions executed under the Standing Payment Mandate. Such classification may include, without limitation: (a) Merchant-Initiated Transactions (MITs); (b) transactions executed pursuant to a standing payment mandate; (c) pre-authorised payment transactions; or (d) such other classification as the Authorised Regulated Partner may determine.

11.4.3 LookPay’s Limited Role. LookPay, as a Technical Service Provider within the meaning of Article 3, does not determine, and makes no representation or warranty as to, the regulatory classification of transactions executed under this Agreement.

11.4.4 Independence of Consent from Regulatory Classification. The User expressly acknowledges and agrees that: (a) The legal validity, enforceability, and contractual effectiveness of the User’s consent to each Payment Request do not depend upon any particular regulatory classification of the underlying transaction. (b) The User’s consent is independently sufficient to satisfy the requirements of applicable contract law, the European Union (Payment Services) Regulations 2018, and PSD2. (c) In the event that a Regulatory Authority or court determines that transactions under the Standing Payment Mandate do not fall within a particular regulatory classification, such determination shall not invalidate or impair the User’s consent.

11.4.5 User’s Agreement to Cooperate. The User agrees to cooperate reasonably and in good faith with LookPay and the Authorised Regulated Partner in the event that a Regulatory Authority requires additional information, documentation, or evidence concerning the consent architecture or the operation of the Standing Payment Mandate.

11.5 SCA at Mandate Creation and at Each Top-Up. The User acknowledges and agrees that:

(a) The initial establishment and execution (signing) of the Standing Payment Mandate was performed by the User through an affirmative biometric confirmation (fingerprint or facial scan) constituting a full Strong Customer Authentication (SCA) procedure at the time of Account creation, conducted in accordance with the EBA Regulatory Technical Standards on SCA (Commission Delegated Regulation (EU) 2018/389). This biometric SCA event applies three independent authentication elements drawn from all three categories required by PSD2: (i) possession — the User’s registered and device-bound User Device, verified through hardware identifiers and cryptographic session tokens; (ii) inherence — the biometric confirmation (fingerprint or facial scan) provided by the User through the App at the point of mandate execution; and (iii) knowledge — the User’s Account password or PIN entered during the initial login session immediately preceding the mandate execution. The application of all three SCA categories exceeds the minimum PSD2 requirement of at least two independent elements from two or more categories and provides the highest available assurance level for the establishment of the mandate.

(b) Each subsequent top-up of the E-Wallet requires a further, independent SCA procedure applied by the Authorised Regulated Partner directly to the underlying funding source on its own banking rails. LookPay does not participate in, control, or assume any responsibility for the SCA procedure applied by the Authorised Regulated Partner to any top-up transaction.

(c) Having provided biometric SCA at the point of mandate execution (Stage One, Account creation), the requirement for Strong Customer Authentication under PSD2 has been discharged in a manner consistent with the front-loaded authentication model described in the EBA Opinion on SCA, and no further SCA event is required at the point of each individual transaction executed under the Standing Payment Mandate. Dynamic Linking via Audio Recording. The audio recording of the initials and amount call-out, as captured by the Merchant Terminal under Article 11.3.2(j), serves to dynamically link the specific transaction amount and the User’s identity (by initials) to the User’s contextual consent, thereby satisfying the dynamic linking requirements of Article 97(2) of PSD2 and Articles 4 and 5 of Commission Delegated Regulation (EU) 2018/389.

(d) The User’s agreement under this Article 11.5 is without prejudice to the User’s rights under PSD2 and the European Union (Payment Services) Regulations 2018, including the right to dispute unauthorised or incorrectly executed payment transactions under Articles 73, 76, 77, and 80 of PSD2, and the right to seek redress through the Financial Services and Pensions Ombudsman as described in Article 34.3.

(e) Voluntary Consumer Safeguard Exceeding PSD2 Requirements. The User expressly acknowledges and agrees that, under the regulatory classification of each transaction as a Merchant-Initiated Transaction (MIT) executed pursuant to a standing payment mandate, the individual application of Strong Customer Authentication at the point of each transaction is not required by Article 97 of PSD2, the EBA Regulatory Technical Standards on SCA (Commission Delegated Regulation (EU) 2018/389), or the European Union (Payment Services) Regulations 2018. The User’s SCA obligation under PSD2 was fully discharged at the point of mandate execution (Stage One, Account creation) as described in Article 11.5(a). Notwithstanding the absence of any legal or regulatory requirement to do so, LookPay has voluntarily elected — as a matter of good faith, consumer protection, and enhanced security — to implement the LookPay Integrity Engine described in Article 11.6, including the Dynamic Risk Threshold, the soft intervention mechanism described in Article 11.6.2(g), and the mandatory SCA intervention described in Article 11.6.3. The Integrity Engine and all associated interventions are voluntary enhancements provided by LookPay at its own cost and initiative. They exceed the minimum requirements of PSD2 and the European Union (Payment Services) Regulations 2018, and they shall not be construed as: (i) an admission by LookPay that any transaction under the Standing Payment Mandate would otherwise require SCA under applicable law; (ii) a waiver of the MIT classification of transactions; (iii) a concession that the front-loaded SCA model is insufficient; or (iv) the creation of any higher standard of care, duty, or obligation than that which would apply in the absence of such voluntary measures.

11.6 The LookPay Integrity Engine — Dynamic Risk Threshold and Mandatory SCA Intervention.

11.6.1 Establishment and Purpose. LookPay has implemented a proprietary automated risk-screening system known as the LookPay Integrity Engine (“the Integrity Engine”). The Integrity Engine employs advanced artificial intelligence and machine learning (AI/ML) algorithms to analyse, score, and screen every Payment Request initiated under the Standing Payment Mandate in real time, prior to routing to the Authorised Regulated Partner for execution. The purpose of the Integrity Engine is to detect transactions that fall outside the User’s established behavioural and financial baseline and to intervene — by suspending the Standing Payment Mandate for that specific transaction and requiring fresh Strong Customer Authentication — before any abnormal or potentially erroneous debit can be executed. The Integrity Engine is a mandatory, non-discretionary component of the LookPay proximity checkout ecosystem and operates as a binding consumer safeguard for every transaction, whether the transaction amount is large or small.

11.6.2 Dynamic Risk Threshold. The Integrity Engine applies a multi-factorial, dynamically adjusting risk threshold (the “Dynamic Risk Threshold”) to each Payment Request. The factors taken into account by the Integrity Engine in setting and applying the Dynamic Risk Threshold include, without limitation:

(a) NACE-Code Merchant Category Analysis. The statistical deviation of the transaction amount from the User’s historical spend pattern within the same NACE code merchant category.

(b) Merchant-Specific Historical Baseline. The deviation of the transaction amount from the User’s own historical average transaction amount at that specific Merchant, or, where the User has no prior transaction history with that Merchant, from the average transaction amount of the User’s demographic cohort at merchants of a similar type, size, and location.

(c) Geographical Velocity. The time elapsed since the User’s immediately preceding transaction at a different geographical location, analysed in conjunction with the physical distance between the two locations.

(d) Transaction Frequency Anomalies. The frequency of Payment Requests initiated on the User’s Account within a rolling time window.

(e) Amount Deviation from User’s Statistical Norm. The ratio of the transaction amount to the User’s median and mean transaction amounts across all historical transactions, weighted by recency.

(f) Additional Risk Indicators. Such other factors, indicators, signals, or data points as the Integrity Engine may from time to time be configured to take into account, including but not limited to: time-of-day analysis, day-of-week analysis, Merchant Terminal integrity signals, simultaneous Proximity Check-Ins from the same Account at different locations, abnormal latency in the transaction flow, and inputs from external fraud databases, sanctions lists, and law enforcement intelligence feeds.

(g) Pre-Authorisation Amount Verification (Soft Intervention). Where the Integrity Engine determines that a Payment Request exceeds the Dynamic Risk Threshold under any of the factors set out in Articles 11.6.2(a) through 11.6.2(f) but the degree of deviation is marginal, or where the Integrity Engine assesses that additional contextual verification could resolve the risk flag without requiring full SCA, the Integrity Engine may, in its discretion, apply a soft intervention before escalating to mandatory SCA under Article 11.6.3. Under this soft intervention, LookPay shall dispatch a pre-authorisation notification to the User’s Device (such as a prompt to confirm the User’s exact location, to verify their identity through a lightweight device-based check, or to confirm that they are currently present at the identified Merchant’s premises and intend to authorise the specific amount). Where the User responds to the pre-authorisation notification to the Integrity Engine’s satisfaction, the Integrity Engine may: (i) reduce the risk score for that Payment Request below the Dynamic Risk Threshold; (ii) permit the Payment Request to proceed without requiring fresh SCA under Article 11.6.3; and (iii) record the soft intervention as a verified risk event in the Server Records. Where the User fails to respond, or where the response does not resolve the risk flag to the Integrity Engine’s satisfaction, the Integrity Engine shall escalate the Payment Request to mandatory SCA intervention under Article 11.6.3.

11.6.3 Mandatory SCA Intervention Where Dynamic Risk Threshold Is Exceeded. Where the Integrity Engine determines that a Payment Request exceeds the Dynamic Risk Threshold, the following consequences shall apply automatically and mandatorily:

(a) Suspension of the Standing Payment Mandate for That Transaction. The Standing Payment Mandate shall be automatically suspended in respect of that specific Payment Request only.

(b) Mandatory Strong Customer Authentication (Passkey / Biometric). LookPay shall prompt the User, via the App, to provide a fresh Strong Customer Authentication event comprising biometric confirmation (fingerprint, facial scan, or passkey) before the Payment Request may proceed.

(c) Notification. LookPay shall dispatch a notification to the User’s Device explaining that the Integrity Engine has flagged the transaction and that biometric confirmation is required to proceed.

(d) Grace Period Unaffected. The Grace Period under Article 12 shall continue to apply to any Payment Request that proceeds following the User’s provision of SCA under this Article 11.6.3.

(e) Decline Where SCA Not Provided. If the User does not provide the required biometric confirmation within a reasonable period, the Payment Request shall be declined in its entirety and shall not be routed to the Authorised Regulated Partner for execution.

11.6.4 Relationship with Other SCA Events. The mandatory SCA intervention under Article 11.6.3 is distinct from, and operates in addition to: (a) the biometric SCA event at Account creation under Article 11.2(a); and (b) any ancillary biometric verification that LookPay may request under Article 11.6.

11.6.5 Consumer Safeguard Characterisation. The User expressly acknowledges and agrees that the LookPay Integrity Engine and the Dynamic Risk Threshold are designed and operated for the User’s protection as well as for LookPay’s. By contractually obliging itself to screen every Payment Request through the Integrity Engine and to require fresh SCA where the Dynamic Risk Threshold is exceeded, LookPay provides an additional layer of consumer protection that exceeds the minimum requirements of PSD2 and the European Union (Payment Services) Regulations 2018. The User agrees that the Integrity Engine’s intervention does not give rise to any right of action, claim, or demand against LookPay, whether in contract, tort, or otherwise, and that LookPay’s sole obligation is to operate the Integrity Engine using reasonable skill and care on a commercially reasonable efforts basis, without any guarantee that every anomalous transaction will be detected or that every legitimate transaction will pass the Dynamic Risk Threshold without requiring SCA.

11.7 Critical Transaction Alert and Routing of Merchant-Initiated Transaction to the Authorised Regulated Partner. Immediately upon the Merchant’s entry of the amount on the Merchant Terminal and the successful validation of all Conditions Precedent, LookPay’s backend infrastructure shall: (i) dispatch a Critical Transaction Alert to the User’s Device notifying the User that a Merchant-Initiated Transaction (MIT) has been initiated by the Merchant (as payee) under the Standing Payment Mandate; and (ii) route the validated Payment Request (being the Merchant-Initiated Transaction) to the Authorised Regulated Partner, instructing it to place a hold on the corresponding amount in the User’s E-Wallet pending the expiry of the Grace Period. The Critical Transaction Alert shall contain: (a) the Merchant’s trading name; (b) the Merchant’s location; (c) the precise amount of the hold; (d) the date and time at which the Payment Request was initiated; (e) the duration of the applicable Grace Period; and (f) a clear indication of the mechanism by which the User may initiate a formal dispute.

11.8 Merchant Integrity, Due Diligence, and Abuse Offloading. LookPay conducts risk-based due diligence on all Merchants prior to onboarding and on an ongoing basis. LookPay reserves the right to suspend or permanently terminate any Merchant found to be misusing the LookPay platform, including without limitation where a Merchant: (a) enters a fraudulent, inflated, incorrect, or duplicate transaction amount; (b) selects a Facial Authentication Profile that does not correspond to the natural person physically present; (c) processes transactions outside the Merchant’s approved business category; (d) engages in identity spoofing, collusion, systemic overcharging, or any form of payment fraud; (e) fails to comply with the visual identification requirements; or (f) otherwise breaches the terms of the Merchant agreement. Where LookPay determines that a Merchant has engaged in any such conduct, LookPay may take remedial action including reversing a hold, requesting claw back of settled funds, suspending or terminating the Merchant, and reporting to relevant authorities.

Part E — The Grace Period, Dispute Resolution, and Final Settlement

Article 12 — Pending Hold and Revocation Grace Period

12.1 Immediate Hold upon Routing. Upon LookPay routing the validated Payment Request to the Authorised Regulated Partner in accordance with Article 11.7, the Authorised Regulated Partner shall immediately place a hold on the corresponding amount in the User’s E-Wallet. This amount shall be sequestered and unavailable for any other transaction or redemption while the hold is active.

12.2 Grace Period Commencement and Duration. The Revocation Grace Period shall commence at the exact moment the Critical Transaction Alert is dispatched. The duration of the Grace Period shall be a period specified within the App for each transaction, falling strictly between five (5) and twelve (12) hours. The User may view the expiry time in the transaction details screen.

12.3 Right to Dispute. During the Grace Period, the User may, through the App, initiate a formal dispute by selecting the relevant transaction and providing a reason (e.g., incorrect amount, duplicate billing, goods not received). Upon initiation of a dispute, the hold shall remain in place, but the automatic settlement to the Merchant shall be halted pending an investigation by LookPay. LookPay will review the circumstances, consult with the Merchant and the User as necessary, and make a determination, in its reasonable discretion, to either release the hold back to the User or proceed with settlement. The decision is final subject only to the User’s right to seek redress through external channels as described in Article 34.

12.4 Constructive Ratification. If the User fails to initiate a dispute within the Grace Period, the User is deemed to have unconditionally and irrevocably ratified the transaction as accurate and authorised. Following expiry of the Grace Period, the transaction will be treated as authorised for operational purposes, without prejudice to any mandatory rights the User may have under applicable law.

12.5 Dispute Dismissal Where Objective Evidence Contradicts User. Where the User initiates a dispute under Article 12.3 and LookPay, in the course of its investigation, obtains CCTV footage under Article 10.4(b) or audio recordings under Article 11.3.2(j) that objectively confirm: (a) that the User’s initials and the transaction amount were announced or displayed at the billing counter in the User’s presence; (b) that the User remained present and did not object, withdraw, or communicate dissent; and (c) that the amount announced or displayed matches the amount entered on the Merchant Terminal, then LookPay shall be entitled, in its sole and reasonable discretion, to dismiss the dispute, release the hold to the Merchant, and proceed with settlement in accordance with Article 13.1. In such circumstances, the User acknowledges and agrees that the dispute is resolved against the User and that the User shall have no further right to challenge the settlement except through the external redress mechanisms described in Article 34.

12.6 User Co-operation Obligation in Disputes. Where the User initiates a dispute under Article 12.3, the User shall, within seven (7) calendar days of LookPay’s written request, provide a detailed written statement of the User’s account of the disputed events, including: (a) the User’s recollection of the amount announced or displayed at the billing counter; (b) whether the User heard or saw the call-out of initials and amount; (c) whether the User raised any objection at the point of sale; and (d) any other facts or circumstances the User considers relevant to the dispute. If the User fails to provide such a statement within the stipulated timeframe, or if the statement provided is materially incomplete, LookPay shall be entitled to resolve the dispute based solely on the Server Records (including audio recordings and CCTV footage) in its possession, without drawing any adverse inference against LookPay or the Merchant by reason of the User’s non-co-operation.

Article 13 — Irrevocable Settlement and Post-Settlement Disputes

13.1 Capture. Upon expiration of the Grace Period without a dispute, the Payment Request shall be deemed authorised and the Authorised Regulated Partner shall immediately capture the held funds and execute a peer-to-peer ledger transfer, crediting the Merchant’s account with the exact amount. LookPay thereafter generally cannot reverse, recall, or alter the settlement, and the Authorised Regulated Partner is not obliged to reverse, recall, or alter the settlement once executed.

13.2 Post-Settlement Merchant Commercial Disputes. Any grievance relating to the quality, fitness for purpose, safety, or delivery of goods or services, or any claim for a refund on grounds other than an error in the amount displayed, lies exclusively against the Merchant. LookPay shall not act as an intermediary, mediator, or refund processor for post-settlement disputes, unless it has exercised its discretion under Article 11.8 to pursue a Merchant for fraud.

Part F — Prohibited Activities, System Abuse, and Security

Article 14 — Acceptable Use and Prohibited Conduct

14.1 Prohibited Conduct. The User shall use the Services solely for lawful, personal, consumer transactions and shall not, under any circumstances, directly or indirectly:

• Violate any applicable local, national, or international law, statute, ordinance, or regulation.
• Use the Services for any activity related to money laundering, terrorist financing, tax evasion, or sanctions circumvention.
• Upload a Facial Authentication Profile that depicts any person other than the User, or that is digitally altered, AI-generated, or otherwise inaccurate.
• Attempt to spoof, simulate, or manipulate the Proximity Check-In by using GPS spoofing applications, VPNs intended to obscure location, Bluetooth relay attacks, signal amplification, or any other technique to falsely indicate physical presence.
• Reverse engineer, decompile, disassemble, decode, or otherwise attempt to derive the source code, proprietary protocols, or cryptographic logic of the App, Merchant Terminal software, or backend services.
• Use any automated system, bot, scraper, or macro to interact with the Services.
• Interfere with or disrupt the integrity or performance of the Services, servers, or networks connected to the Services.
• Use the E-Wallet to facilitate transactions involving unlicensed gambling, adult entertainment, unregistered cryptocurrency exchanges, weapons, narcotics, or any goods or services prohibited by the Acceptable Use Policy.
• Create multiple accounts for the purpose of circumventing limits, sanctions, or account restrictions.
• Allow any third party to use their Account or Facial Authentication Profile to conduct transactions.

Article 15 — Device Integrity and Gross Negligence

15.1 Absolute User Responsibility. The security architecture of LookPay relies upon the untampered integrity of the User Device. The User accepts absolute, non-delegable responsibility for maintaining the physical and digital security of the User Device.

15.2 Definition of Gross Negligence. For the purposes of this Agreement, and consistent with Article 74 of PSD2 and the Irish Payment Services Regulations, the User shall be fully liable for all unauthorised transactions where such transactions arise from the User’s gross negligence. The following acts or omissions shall, without limitation, may be deemed to constitute gross negligence: (a) Disabling the device’s screen lock, PIN, password, or biometric authentication entirely, or configuring it in a manner that allows easy bypass. (b) Enrolling the biometrics (fingerprint, face) of any third party onto the User Device. (c) Using the App on a device that has been “rooted”, “jailbroken”, or otherwise modified to override manufacturer security protections or operating system integrity checks. (d) Failing to notify LookPay of the loss or theft of the User Device within 24 hours of discovery. (e) Intentionally ignoring the Critical Transaction Alert, where the User had a reasonable opportunity to view it and failed to dispute an obviously incorrect amount. (f) Writing down or sharing login credentials or device passcodes with any third party.

15.3 Exclusion of Refund. Where an unauthorised payment transaction occurs as a direct or indirect result of the User’s gross negligence, the User shall bear all losses incurred, and LookPay and the Authorised Regulated Partner shall be under no obligation to provide a refund or reimbursement.

Article 16 — Sanctions and Export Control

16.1 Sanctions Compliance Representation. The User represents that they are not a resident of or located in a jurisdiction that is subject to comprehensive territorial sanctions by the European Union, the United Nations, the United States, or the United Kingdom. The User further warrants that they are not an individual or entity listed on any prohibited or restricted parties list. LookPay reserves the right to block transactions to and from such jurisdictions and to suspend or terminate Accounts without prior notice where sanctions compliance so requires.

Part G — Limitation of Liability, Disclaimers, and Indemnification

Article 17 — No Financial Advice and Service “As Is”

17.1 No Advice. LookPay provides a technology-only proximity checkout interface. Nothing in the App, communications, or documentation constitutes banking, investment, legal, tax, or financial advice.

17.2 “As Is” Basis. Subject only to the mandatory statutory warranties under the Irish Consumer Rights Act 2022 (concerning digital services supplied with reasonable skill and care), the Services are provided on an “AS IS”, “AS AVAILABLE”, and “WITH ALL FAULTS” basis. LookPay disclaims all implied warranties of merchantability, fitness for a particular purpose, and non-infringement to the fullest extent permitted by law.

Article 17A — Service Availability and No Uptime Guarantee

17A.1 No Availability Warranty. LookPay does not guarantee the continuous, uninterrupted, secure, timely, or error-free operation of the Services. The Services are provided on a commercially reasonable efforts basis only.

17A.2 Scheduled and Unscheduled Downtime. LookPay may suspend, interrupt, or limit access to the Services for scheduled or emergency maintenance, security incidents, or regulatory compliance. Critical security patches may be deployed without prior notification.

17A.3 Third-Party Infrastructure Dependency. The Services depend on third-party infrastructure including the Authorised Regulated Partner, cloud hosting providers, mobile network operators, GPS systems, and Bluetooth spectrum, over which LookPay exercises no direct operational control.

17A.4 No Service Level Agreement. No refunds, service credits, or compensation shall be payable for unavailability, save as expressly provided in this Agreement.

17A.5 Regulatory and Partner-Imposed Outages. Where the Authorised Regulated Partner suspends the underlying E-Wallet infrastructure at the direction of a Regulatory Authority, LookPay shall not be liable for any resulting unavailability.

Article 18 — Specific Disclaimers Relating to Technology

18.1 Volatility of Wireless Technologies. LookPay does not warrant that the Services will function correctly in all physical environments, including where affected by radio interference, structural materials, poor network coverage, or GPS inaccuracy.

18.2 No Liability for Merchant Errors. LookPay shall not be liable for loss arising from the Merchant’s erroneous entry of an amount, except where the User has initiated a dispute within the Grace Period.

18.3 Device Battery and Connectivity. The User is responsible for ensuring the User Device is adequately charged and connected to the internet.

18.4 No Liability for Merchant Terminal Audio Recording Failure. The User acknowledges and agrees that the audio recording functionality described in Article 11.3.2(j) and Article 10.4(a) is an evidentiary enhancement and dispute-resolution safeguard only. Where the audio recording fails, is incomplete, corrupted, degraded, or otherwise unavailable — whether due to a technical fault at the Merchant Terminal (including microphone malfunction, storage capacity exhaustion, power interruption, software error, network connectivity failure, or text-to-speech engine error), or due to environmental factors (including ambient noise, acoustic interference, multiple simultaneous conversations, or the physical distance of the User from the Merchant Terminal’s microphone) — such failure or unavailability shall not: (a) invalidate or otherwise affect the validity of any Payment Request, provided that all Conditions Precedent under Article 11.3.2 were satisfied at the time of initiation; (b) give rise to any liability on the part of LookPay to the User or to any third party; (c) create any presumption or inference in favour of the User in any dispute, investigation, or proceeding; or (d) affect the operation of constructive ratification under Article 12.4 or the application of any other provision of this Agreement.

Article 18A — Beta and Experimental Features

18A.1 Definition and Designation of Beta Features. LookPay may offer features designated as “beta”, “alpha”, “experimental”, “pilot”, “early access”, “preview”, “labs”, “trial”, or similar (collectively, “Beta Features”). Beta Features are at an early stage of development and have not undergone the full suite of quality assurance testing or regulatory compliance verification.

18A.2 No Representation, Warranty, or Undertaking. Beta Features are provided strictly on an “AS IS” basis with no warranty. The User acknowledges that Beta Features may contain defects that could result in data loss, transaction failure, or other adverse consequences.

18A.3 Assumption of All Risk. The User’s use of any Beta Feature is entirely voluntary and at their own sole risk. LookPay shall have no liability for any loss arising from the use of any Beta Feature.

18A.4 Modification, Suspension, and Withdrawal. LookPay reserves the absolute right to modify, suspend, or discontinue any Beta Feature at any time without prior notice.

18A.5 Confidentiality Obligations. The User shall not disclose, capture screenshots of, publish reviews of, or reverse engineer any Beta Feature without LookPay’s prior written authorisation.

18A.6 Regulatory Sandbox and Restricted Authorisation. Where a Beta Feature falls within a regulatory sandbox framework, LookPay shall clearly disclose this to the User prior to participation.

Article 19 — Limitation of Liability

19.1 Exclusion of Indirect Damages. To the fullest extent permissible under Irish law, LookPay shall not be liable for any indirect, incidental, special, consequential, punitive, or exemplary damages, including loss of profit, business opportunity, or data.

19.2 Aggregate Liability Cap. Subject to Article 19.3, the maximum total aggregate liability of LookPay shall be limited to the greater of (a) the total amount of funds held in the User’s E-Wallet at the time the liability arose, or (b) fifty euros (€50.00) except where prohibited by mandatory law.

19.3 Non-Excludable Liabilities. Nothing in this Agreement shall limit or exclude LookPay’s liability for death or personal injury caused by proven negligence, fraud, or any liability that cannot be lawfully excluded under mandatory Irish or EU law.

Article 19A — Preservation of Statutory Consumer Rights

19A.1 Statutory Rights Unaffected. Nothing in this Agreement shall operate to exclude, restrict, or modify any right conferred upon the User by statute that cannot lawfully be excluded by private agreement.

19A.2 Non-Derogable Consumer Protections. The User’s mandatory statutory rights under the Consumer Rights Act 2022, the European Union (Payment Services) Regulations 2018, the GDPR, and other applicable consumer protection legislation are expressly preserved.

19A.3 Rule of Construction in Favour of the Consumer. Any term found to be inconsistent with mandatory statutory rights shall be enforced only to the maximum extent consistent with such rights, and if entirely unenforceable, shall be severed.

19A.4 No Waiver of Statutory Rights. Any provision that might be construed as a waiver of a mandatory statutory right is expressly declared to be ineffective and void.

19A.5 Positive Affirmation. LookPay affirmatively acknowledges and respects the User’s mandatory statutory consumer rights.

Article 20 — Indemnification by the User

20.1 Indemnification Obligation. The User agrees to indemnify LookPay against claims arising from: (a) the User’s breach of this Agreement; (b) the User’s gross negligence; (c) the User’s fraudulent or malicious use of the Services; and (d) any violation by the User of applicable law.

Part H — Intellectual Property, Open Source, and App Store Terms

Article 21 — Ownership and Licence Grant

21.1 Ownership. All right, title, and interest in and to the App, the Merchant Terminal software, the backend infrastructure, the proprietary proximity protocol, the LookPay name and logo, and all related intellectual property are and shall remain the exclusive property of LookPay Limited and its licensors.

21.2 Limited Licence. Subject to compliance with this Agreement, LookPay grants the User a limited, non-exclusive, non-transferable, revocable licence to download and install the App.

21.3 Open Source Components. Certain components may be subject to open-source licences. LookPay will make applicable attributions available within the App.

Article 22 — Third-Party Platform Conditions (App Stores)

22.1 App Store Acknowledgment. If the App is downloaded from the Apple App Store or Google Play Store, the User acknowledges that this Agreement is between the User and LookPay only, and the platform provider has no obligation to furnish support services.

Article 22A — Copyright and Intellectual Property Complaints

22A.1 Respect for IP Rights. LookPay respects intellectual property rights and responds promptly to legitimate notices of alleged infringement.

22A.2 Designated Agent. Notifications of claimed infringement must be submitted in writing to LookPay’s Intellectual Property Agent at LookPay Limited, Letterkenny, County Donegal, Ireland. Email: copyright@lookpay.app

22A.3 Requirements for a Valid Takedown Notice. A Takedown Notice must include: (a) signature of the rights owner; (b) identification of the IP Right; (c) identification of the infringing material; (d) contact information; (e) a good faith belief statement; (f) a statement of accuracy under penalty of perjury; and (g) where applicable, compliance with Article 16 of Directive (EU) 2019/790.

22A.4 Counter-Notification. Users or Merchants may submit a Counter-Notice if they believe material was removed by mistake.

22A.5 Action by LookPay. LookPay shall promptly take appropriate action in response to a Takedown Notice, which may include removing the material and suspending the Account.

22A.6 Repeat Infringer Policy. LookPay may terminate Accounts of repeat infringers (two or more valid Takedown Notices within a rolling twelve-month period).

22A.7 Immunity and Indemnification. LookPay shall not be liable for actions taken in good faith in response to a Takedown Notice.

22A.8 LookPay Not an Adjudicator. LookPay is not obligated to adjudicate disputes between Users, Merchants, and IP Rights holders.

22A.9 Compliance with EU Digital Services Act. LookPay shall comply with its obligations under Regulation (EU) 2022/2065 (DSA).

Part I — Data Protection, Privacy, and Electronic Communications

Article 23 — Privacy Policy Incorporation

23.1 Incorporation by Reference. LookPay’s data processing is governed by the Privacy Policy, available at lookpay.app/privacy.

23.2 Data Subject Rights. The detailed procedures for exercising GDPR rights are set out in the Privacy Policy, which shall prevail over this Agreement in case of any inconsistency regarding data protection.

23.3 Facial Authentication Profile — Standard Photograph (Not Biometric Data). The Facial Authentication Profile is a standard digital photograph uploaded by the User, similar to a social media profile picture. It is not a biometric scan, biometric template, facial recognition hash, or any other form of biometric data within the meaning of Article 4(14) of the GDPR. LookPay does not perform automated facial recognition, biometric matching, or any other form of algorithmic biometric processing on this photograph. The photograph is stored and transmitted in its original visual form and is displayed on the Merchant Terminal solely for the purpose of enabling a human employee of the Merchant to perform a visual comparison between the photograph and the person physically present at the billing counter. This is the same kind of visual identity check that a bartender performs when comparing a customer to a photo ID — it is a manual, human-driven verification process, not an automated biometric identification system. The legal basis for processing the photograph is the performance of a contract (Article 6(1)(b) GDPR), as the display of the photograph on the Merchant Terminal is an essential feature of the proximity checkout service contracted by the User. The User’s display consent under Article 10.2 supplements this contractual basis.

Article 24 — Electronic Communications and Notices

24.1 Consent to Electronic Communications. The User agrees to receive all communications from LookPay electronically, including Critical Transaction Alerts, account updates, and security notices.

24.2 Legal Effect. Electronic communications satisfy any legal requirement that such communications be in writing.

Article 24A — Data Portability and Export Rights

24A.1 Right to Data Portability. In accordance with Article 20 of the GDPR, the User has the right to receive a copy of their personal data in a structured, machine-readable format.

24A.2 Scope of Exportable Data. The export includes account registration data, complete transaction history (not less than six years), E-Wallet top-up and redemption history, the Facial Authentication Profile photograph and initials, and consent history.

24A.3 Excluded Data. Data portability does not extend to AML/CTF compliance data, anonymised data, third-party personal data, proprietary algorithms, server logs, privileged communications, or data whose export is prohibited by law.

24A.4 Request Procedure. Requests may be submitted through the App, by email to privacy@lookpay.app, or by post. LookPay shall acknowledge receipt within five (5) business days and complete the export within thirty (30) calendar days.

24A.5 Identity Verification. LookPay shall verify the identity of the requestor before releasing data.

24A.6 Fees. The first data export within any twelve-month period is free of charge.

Article 24B — Electronic Evidence and Admissibility of Server Records

24B.1 Server Records as Prima Facie Evidence. The Server Records shall constitute prima facie evidence of the facts they record and shall be admissible in any legal, regulatory, arbitral, or ombudsman proceedings.

24B.2 Categories of Server Records. The Server Records include: (a) Account creation records; (b) Proximity Check-In event logs; (c) Payment Request and transaction logs; (d) Grace Period records; (e) E-Wallet ledger records; (f) Communication and notification logs; (g) Security event logs; (h) Consent and acceptance records; (i) Merchant Terminal audio recording logs; and (j) CCTV footage obtained from the Merchant’s premises.

24B.3 Evidentiary Weight. The Server Records shall be treated as accurate absent clear and convincing evidence to the contrary. CCTV footage and audio recordings shall each constitute prima facie evidence of the facts they depict or record.

24B.4 Waiver of Evidentiary Objections. The User waives any right to object to the admissibility of the Server Records on grounds of hearsay, lack of an original document, or electronic storage format.

24B.5 Statutory Foundation. This provision is supported by the Electronic Commerce Act 2000 (Ireland), the eIDAS Regulation, and PSD2.

24B.6 Retention. LookPay shall retain Server Records for a minimum of six (6) years. The User may request copies by written request to legal@lookpay.app.

24B.7 No Duty of Proactive Disclosure. LookPay has no duty to proactively disclose Server Records save where required by law or court order.

24B.8 Survival. This Article shall survive termination of this Agreement.

Part J — Term, Suspension, and Termination

Article 25 — Term

25.1 Commencement and Duration. This Agreement shall commence upon the User’s first use of the Services and shall continue indefinitely until terminated.

Article 26 — Termination by the User

26.1 Termination by User. The User may terminate this Agreement at any time by closing the Account through the App or by sending a request to support@lookpay.app.

Article 27 — Suspension and Termination by LookPay

27.1 Grounds for Suspension or Termination. LookPay may immediately suspend or terminate the User’s Account upon breach of this Agreement, regulatory suspension of the E-Wallet, law enforcement request, suspected fraud, failure to provide CDD information, or the User’s death or incapacity.

27.2 Effect of Termination. Upon termination, the User’s right to use the Services shall immediately cease. LookPay will cooperate with the Authorised Regulated Partner to return any remaining E-Money balance.

Article 27A — Dormant Accounts

27A.1 Definition of Dormancy. An Account is classified as Dormant where no user-initiated activity has occurred for twenty-four (24) months.

27A.2 Pre-Dormancy Notification. LookPay shall use reasonable endeavours to notify the User at least thirty (30) calendar days before the Account becomes Dormant.

27A.3 Consequences of Dormancy. The Account shall be suspended and a monthly Dormancy Fee may be deducted from the E-Wallet balance, capped at the lesser of the total balance or twenty-four (24) months of fees.

27A.4 Escheatment. After five (5) years of dormancy, LookPay may transfer the residual balance to the relevant state authority.

27A.5 Reactivation. The User may request reactivation by contacting support@lookpay.app, subject to satisfactory identity verification.

27A.6 Regulatory Basis. This Article complies with the Dormant Accounts Act 2001 (Ireland) and applicable Central Bank of Ireland requirements.

27A.7 Exclusion of Liability. LookPay shall not be liable for any loss arising from the classification, fee deduction, or escheatment of a Dormant Account.

Article 28 — Survival

28.1 Surviving Provisions. The provisions of Articles 3, 8, 10.2, 10.4, 14–20, 17A, 18A, 19A, 21.1, 22A, 23, 24A, 24B, 27A, 28, 29–34, 33A, 33B, and any other provisions that by their nature should survive termination, shall so survive and continue in full force and effect.

Part K — Force Majeure, Amendments, and General Provisions

Article 29 — Force Majeure

29.1 Force Majeure Events. LookPay shall not be liable for any failure or delay resulting from a Force Majeure Event, including acts of God, natural disasters, governmental actions, internet backbone failures, GPS satellite degradation, cloud service provider outages, and insolvency of the Authorised Regulated Partner.

Article 30 — Assignment and Subcontracting

30.1 Assignment Restrictions. The User may not assign rights under this Agreement without LookPay’s prior written consent. LookPay may freely assign its rights to any affiliate or successor.

Article 31 — Entire Agreement and Conflict

31.1 Entire Agreement. This Agreement represents the entire understanding between the parties, except that the Privacy Policy shall govern data protection matters in case of inconsistency.

Article 32 — Amendment to the Agreement

32.1 Right to Amend. LookPay may modify this Agreement. Material modifications are subject to at least two (2) months’ written notice. Continued use after the effective date constitutes acceptance.

Article 33 — Relationship of the Parties

33.1 Relationship. Nothing in this Agreement shall create a partnership, joint venture, or agency relationship between the User and LookPay.

Article 33A — Tax Liability and Indemnification

33A.1 Sole Responsibility. The User is solely responsible for all taxes arising from their use of the Services, including VAT, income tax, customs duties, and digital services taxes.

33A.2 No Tax Advice. LookPay does not provide tax advice. The User is advised to consult a qualified tax professional.

33A.3 No Withholding Obligation. Unless required by law, LookPay has no obligation to withhold or report Taxes.

33A.4 Tax Indemnity. The User agrees to indemnify LookPay against any claims arising from the User’s failure to comply with tax obligations.

33A.5 Tax Information Requests. The User shall provide tax information as reasonably requested by LookPay within fourteen (14) calendar days.

33A.6 VAT on LookPay Fees. Fees subject to VAT shall be stated exclusive of VAT.

33A.7 Change in Tax Circumstances. The User shall promptly notify LookPay of any material change in tax residency.

Article 33B — Security Vulnerability Reporting and Responsible Disclosure

33B.1 Commitment to Security. LookPay recognises the valuable contribution of security researchers.

33B.2 Scope. This policy applies to vulnerabilities discovered in the LookPay mobile app, backend APIs, Merchant Terminal software, Proximity Check-In protocol, and public-facing websites.

33B.3 Excluded Activities. Social engineering, DoS testing, and destruction of data are excluded from this policy.

33B.4 Disclosure Procedure. Reporters shall submit detailed reports to security@lookpay.app and shall not publicly disclose vulnerabilities for at least ninety (90) calendar days.

33B.5 Safe Harbour. LookPay covenants not to sue Reporters who comply with this policy.

33B.6 LookPay’s Obligations. LookPay shall acknowledge receipt within five (5) business days and conduct a prompt investigation.

33B.7 No Bounty. LookPay does not currently operate a paid bug bounty programme.

33B.8 Reservation of Rights. LookPay reserves the right to pursue legal remedies against bad-faith actors.

Article 33C — Accessibility Statement

33C.1 Commitment to Digital Inclusion. LookPay is committed to making the App accessible to Users with disabilities, consistent with the European Accessibility Act (Directive (EU) 2019/882) and the Irish Disability Act 2005.

33C.2 Accessibility Standards. LookPay applies WCAG 2.1 at Level AA to the extent commercially reasonable, including compatibility with VoiceOver and TalkBack, support for dynamic text sizing, and adequate colour contrast.

33C.3 Inherent Service Limitations. Certain features present inherent accessibility constraints: the Proximity Check-In requires a location-enabled device; the Facial Authentication Profile requires a clear photograph; the Critical Transaction Alert is delivered as a push notification.

33C.4 No Representation of Full Conformance. LookPay does not represent that the App fully conforms to WCAG 2.1 Level AA.

33C.5 Third-Party Components. Accessibility may be limited in respect of Merchant Terminal hardware, third-party libraries, and operating system-level features.

33C.6 Feedback. Users who encounter accessibility barriers may contact accessibility@lookpay.app.

Article 34 — Governing Law and Dispute Resolution

34.1 Governing Law. This Agreement shall be governed exclusively by the laws of the Republic of Ireland.

34.2 Mandatory Internal Complaint Procedure. Before initiating legal action, the User must submit a written complaint to legal@lookpay.app. LookPay will acknowledge receipt within five (5) business days.

34.3 Financial Services and Pensions Ombudsman (FSPO). If not satisfied after the internal process, the User may refer the matter to the FSPO in Dublin, Ireland.

34.4 Jurisdiction. Subject to the User’s right as a consumer domiciled in the EEA to bring proceedings in their own domicile, the parties submit to the exclusive jurisdiction of the courts of Ireland, sitting in Dublin.

Part L — Contact and Notices

Article 35 — Contact and Notices