Aamalak Platform Data Protection Policy

These requirements apply to employees, authorized users and suppliers who process platform data within their roles, and to the website, applications, APIs, integrations, documents, outputs, logs and backups connected to them.

The Company complies with the Personal Data Protection Law, its Implementing Regulation and the Regulation on Personal Data Transfer outside the Kingdom. It determines the scope of the cybersecurity controls that apply to it based on its activity, classification and regulator, including the relevant National Cybersecurity Authority controls: the Essential Cybersecurity Controls (ECC), the Data Cybersecurity Controls (DCC), the Cloud Cybersecurity Controls (CCC) and, where applicable, the controls for non-critical-infrastructure private-sector entities (NCNICC).

The Saudi Central Bank instructions applicable to the activity and service under its supervision are also observed, including requirements for cybersecurity, outsourcing, open banking and customer data protection, according to the scope of the licence or approval. This policy is not used to claim the existence of a licence or accreditation that has not been issued.

Management approves the policy, provides resources and monitors risk. An owner is assigned to each asset or data set to decide its classification and the limits on its use and retention, with a clear division of responsibilities between data protection, cybersecurity, technology, compliance and operations.

A personal data protection officer is designated or appointed where the law requires it, and is given sufficient authority and resources, with conflicts of interest addressed. The cybersecurity function monitors controls, incidents and risks within the applicable organizational-independence requirements.

The Company assesses whether it must register in the National Register of Controllers and keeps its entry up to date when registration is required. Approvals, exceptions and corrective actions are documented, and no internal exception may permit a breach of a mandatory legal provision.

The Company inventories its data, its sources, storage locations, flows, recipients and sub-processors, including external services and remote access. Classification is based on the impact of disclosure, modification, loss or unavailability and on legal and contractual requirements.

Access, encryption, sharing, retention and deletion requirements are set for each category. Data is not considered published or public merely because it is on the internet if making it available was unlawful. Sensitive data and personal credit data are treated separately from the internal business classification.

Financial and business information is protected even when it contains no personal data, with a clear separation between a business’s rights in its files and the rights of the individuals whose data appears in them.

The purpose and legal basis are set before processing begins, the required notices are given and consents are documented where needed. Information is not collected just in case for an unspecified future use, and the purpose is not changed without meeting the legal requirements.

Input forms, files and APIs are reviewed to ensure only the necessary data is collected. Bank sign-in secrets and verification codes are kept out of support files and logs, and processing of copies of official identity documents is limited to the cases the law allows.

A mechanism exists to correct data and to stop processing that has an effect if the data proves inaccurate or incomplete and could harm the person concerned, with the parties to whom the data was disclosed notified of the correction in line with the applicable obligations.

Privacy and security requirements are built in from the design of the service, the addition of features and the selection of suppliers. Default settings use the minimum data, permissions and sharing, and changes are reviewed before release.

A written impact assessment is carried out before processing that requires one, including processing sensitive data, combining or linking data sets from different sources, and cases involving emerging technologies, monitoring or automated decisions under the conditions of the Regulation. The purpose, legal basis, risks, safeguards and decision are documented, and the assessment is updated when the risks or the scope of processing change.

Legitimate interest is assessed before it is relied on, and it may not be used outside its conditions or to bypass explicit-consent requirements. International-transfer assessment requirements are met separately where they apply.

Access is granted to people and service accounts on a need-to-know, least-privilege basis, with sensitive duties separated, access reviewed periodically and revoked when a relationship ends or a role changes. Privileged and remote access is protected by strong, multi-factor authentication in line with the applicable controls.

Each business’s data, entities and users must be isolated in databases, storage, interfaces and reports. Permissions must be checked on the server for every request, including file-download links and report exports, rather than relying only on hiding interface elements.

Support staff and supplier access to data is limited to a documented business reason and a limited time, and is logged when allowed. Integration keys and secrets are protected in suitable environments, rotated and revoked according to risk and life cycle, and may never be embedded in public code or exposed links.

Sharing data through the EFM Bridge portal is subject to verification of the partner’s identity, capacity and authority to act, and access is limited to the customers who have activated a link with that partner and to the declared data categories. Consent, its scope, date and withdrawal are recorded; future access is revoked when the link ends; and these boundaries are tested so that a referral code cannot be used to extract another customer’s data.

Appropriate encryption and secure protocols are used to protect data in transit, and stored data and backups are protected according to their classification and the applicable controls. Encryption keys are managed separately and securely, with controlled access, recovery, rotation and revocation.

Unrestricted public links to financial or personal files are prohibited, and downloads are limited by permission, scope and an appropriate time window. Export files are reviewed before sharing, and data leakage via email, collaboration tools, media or test environments is limited.

Synthetic or anonymized data is used for development and testing where possible. Where that is not possible, real data is used only with a documented necessity, safeguards, permissions and an appropriate legal basis, and with the level of protection it requires.

Secure-development, code-review, vulnerability-management, patching, and device, network and configuration protection requirements are applied. Security testing and penetration testing are carried out according to risk and the frequency set by the applicable controls, and remediation is tracked until the fix is verified.

File-upload and processing paths are protected against malicious content and tampering, and file types, sizes and scope of use are restricted. APIs are protected against abuse, replay of invalid tokens and unauthorized access, and the isolation boundaries between businesses are tested.

Development, test and production environments are separated, and changes go through review, approval and safe rollback, with plans for handling unsupported versions or suppliers.

The events needed to trace sign-ins, sensitive changes, downloads, exports, permissions, integrations and incidents are logged, with the integrity and timestamps of logs protected, unauthorized modification prevented and access to them restricted.

Logs do not contain passwords, secret tokens or unnecessary copies of documents and transactions. Their retention period is set according to risk and legal requirements; unusual indicators are monitored and alerts reviewed, without monitoring beyond the legitimate purpose.

The Company assesses service providers before contracting and periodically for their security and privacy safeguards, processing locations, responsiveness, and ability to return and delete data. Agreements are concluded that set out the purpose, categories, duration, instructions, confidentiality, security, incident reporting, rights requests and audit.

Where the Company acts as a processor, it appoints a sub-processor only with the controller’s prior approval, after notice before contracting and with the controller able to object within the agreed period. The Company’s responsibilities to the customer remain in place under the law and the contract, and sub-parties are bound by the necessary safeguards.

Assessment of cloud services covers shared responsibilities, data and backup locations, support, encryption keys, and the exit and service-transition plan. The location of the database alone is not relied on to prove that all processing stays inside the Kingdom.

Every transfer, disclosure or access from outside the Kingdom undergoes a legal and technical review that identifies the purpose, data categories, countries, recipients and onward processors, and the conditions of Article 29 and the Transfer Regulation. Appropriate safeguards, the correct legal route and a risk assessment are adopted where required, and the continued validity of those safeguards is monitored.

Any stricter obligation regarding local hosting, outsourcing approvals, or financial and banking data is observed. Processing is stopped or changed if the required conditions cannot be met; general consent or a standard supplier contract is not a substitute for meeting them.

Inputs to artificial intelligence are limited to the data needed for the purpose, and unneeded identifiers are masked where possible. Model providers are assessed for content retention, processing locations, use for training, and access to the data by people and sub-parties.

Customers’ personal data and confidential files are not used to train general-purpose models under a standard subscription. Outputs that may affect financial decisions are reviewed and their limits and data reliability are stated, and a mechanism is available for corrections and related objections.

Explicit consent is obtained where the law requires it for automated processing or sensitive data, and the requirements for credit data apply where data meets the legal definition. The platform does not issue a binding financing decision merely by generating an indicator or report.

The Company adopts a retention schedule that sets, for each category, the purpose, the retention period or the rule for calculating it, when the period starts, the reason for any exception, the deletion method and who carries it out. It covers operational data, attachments, reports, logs and copies held by suppliers.

Protected backups and recovery and continuity plans proportionate to the importance of the service are in place, and recovery is tested periodically. Acceptable recovery and downtime objectives are set internally or in a service-level agreement according to risk, without publishing an unproven time commitment.

When the purpose ends or a deletion request is valid, data is securely removed from systems and suppliers under the approved controls. Any copies kept for a legal obligation or a backup cycle are restricted and may not be reused for another purpose. Deletion and anonymization are documented, and it is verified that re-identification is not possible before data is treated as anonymous; pseudonymization alone does not take data outside the scope of personal data.

Procedures are in place to detect, classify and contain incidents, preserve evidence, investigate, restore service, address the root cause and prevent recurrence. Employees and suppliers report indicators as soon as they are discovered through the defined internal escalation channels.

Where the Company is a controller and a data leak could harm personal data or the people it concerns, or conflict with their rights or interests, it notifies the competent authority within no more than seventy-two hours of becoming aware, in line with the notification requirements. The report includes the available information about the event, the categories and numbers affected, the risks, the measures taken and a contact method, and missing information is supplied as soon as possible with the reasons for the delay.

Affected data subjects are informed without undue delay whenever notifying them is required, in clear language that covers the impact of the incident, the measures taken and appropriate guidance. Where the Company acts as a processor, it informs the controller without undue delay and provides the information needed for the controller to meet its obligations; it does not wait for the regulatory reporting deadline to notify the customer.

Reporting obligations to the National Cybersecurity Authority, the Saudi Central Bank or others are observed in parallel where they apply, through each authority’s channels and deadlines. A report to one authority does not replace the other required reports.

A direct channel is available for data-subject requests, with controls for identity verification, response, correction, deletion and referral to the controller where needed. The thirty-day period for requests and the legal extension rules set out in the Privacy Policy apply, and actions and responses are documented.

The Company keeps records of the processing activities it carries out as a controller, keeps their purposes, data categories, recipients, international transfers, retention and protection up to date, and makes them available to the competent authority on request. These records are kept for the duration of the activity and five years after it ends, as the Regulation requires; this period does not mean all customer data may be kept for the same length of time.

The Company assists the controllers it contracts with on rights requests, impact assessments, incidents and audits within the scope of the service and the data-processing agreement.

Employees receive awareness and training appropriate to their roles, with confidentiality obligations and controls on hiring, change of duties and termination. Training covers handling financial files, phishing, incident reporting and preventing unauthorized sharing.

The policy and its controls are reviewed periodically and whenever the service, risks or regulations change or a significant incident occurs. Test and review results, remediation plans, their deadlines and owners are documented, and the effectiveness of each fix is verified. Publishing the policy is no substitute for implementing the controls or providing evidence of compliance to the competent authorities.

For data protection enquiries or requests: complaint@xsquare.sa. To report a suspected leak or unauthorized access: dpo@xsquare.sa. You can also use the general contact form at https://efm.seentarbi.sa/contact, without attaching secrets or complete financial files to the initial report.

Please include a short description of what happened, when you noticed it and a secure way to contact you, without carrying out penetration tests or viewing other people’s data without permission. This route does not limit a data subject’s right to file a complaint with SDAIA or any other legal obligation.