PRIVACY NOTICE
Comprehensive information about ScoreID’s processing of personal data, profiling, scoring, sharing and individual rights.
Document control |
Details |
|---|---|
Legal entity |
ScoreID B.V., the Netherlands |
Last updated |
28 August 2026 |
Status |
Publication draft |
Review cycle |
At least annually and upon material product, model, legal or data-flow change |
Contact |
hello@scoreid.com |
Important implementation note
This document forms part of ScoreID’s integrated legal and governance framework. It must be implemented consistently in the product interface, model documentation, consent records, customer contracts, data maps, retention controls and rights-handling procedures.
1. Who we are and how to contact us
ScoreID B.V. is a private limited liability company established in the Netherlands. In this Notice, “ScoreID”, “we”, “us” and “our” refer to ScoreID B.V. Where we determine why and how personal data are processed, ScoreID is the controller. Our public Legal Center and contractual documents must display our complete registered address, Chamber of Commerce (KvK) number and any appointed data-protection contact before publication.
Privacy questions, rights requests and complaints may be sent …@scoreid.com with the subject “Privacy Request”. We will not require an individual to create an account solely to exercise a right. Where appointment of a data protection officer or representative is legally required, their current contact details will be published in the Legal Center and incorporated into this Notice.
2. Scope and relationship with customers
This Privacy Notice applies to ScoreID websites, applications, individual accounts, score-generation services, wallet and exchange connections, user-directed sharing, customer dashboards, APIs, support, events and business communications where ScoreID determines the purposes and essential means of processing. It covers information collected directly from an individual and information obtained indirectly from Connected Sources, public blockchains, Institutional Customers or approved providers.
An institution that receives a Score or uses ScoreID in its own onboarding, underwriting, segmentation, approval or account-management workflow normally acts as an independent controller for that decision and subsequent use. Its privacy notice also applies. Where ScoreID processes Customer Personal Data solely on documented instructions, the Customer is the controller and ScoreID is processor under the Data Processing and Role Allocation Addendum; in that situation, the Customer’s notice is the primary notice for the instructed processing.
This Notice does not cover a third party’s independent website, wallet, exchange, financial product or decision process. A link or connection does not mean that ScoreID controls that third party.
3. Key concepts and our privacy roles
“Personal Data” means information relating to an identified or identifiable natural person. A public wallet address, transaction identifier or pseudonymous identifier can be Personal Data where it is linked or reasonably linkable to a person. “Profiling” means automated processing used to evaluate or predict personal aspects such as financial reliability, economic situation, behaviour or risk. “Score” and “Output” have the meanings described in the Terms of Service.
Roles are allocated per processing activity rather than by a blanket label. ScoreID generally acts as controller for direct accounts; technical source verification; the design and governance of a general ScoreID Model; generation and explanation of Scores where ScoreID determines the methodology; security; misuse prevention; legal compliance; service measurement; and direct business communications. An Institutional Customer acts as controller for its own collection, decision, lawful basis, notices, retention, adverse action and rights response.
If ScoreID and another organisation jointly determine a common purpose and essential means, the parties will enter an arrangement under Article 26 GDPR, allocate responsibilities and make the essence available to affected individuals. Joint controllership is not inferred merely because data are transmitted between independent controllers or because one party uses the other’s service.
4. Personal data we process
ScoreID does not request wallet seed phrases or private keys and individuals must never provide them. We do not ordinarily collect gender, race, ethnicity, religion, health information, sexual orientation, political opinions, trade-union membership, biometric identifiers, precise location, criminal-conviction data or other sensitive/protected traits as scoring inputs.
If an approved compliance or fairness-testing programme requires sensitive or protected-trait information, it must be separated from production scoring, access restricted, supported by an applicable Article 9 or national-law condition, and used only for the documented monitoring purpose. It must not influence an individual Score. Government identifiers and full identity-document copies are avoided where a verification result, token or partial identifier is sufficient.
Category |
Illustrative data elements |
Ordinary treatment |
|---|---|---|
Account and contact |
Name where needed; verified email; optional telephone; country/region; account ID; language; organisation, role and administrator status. |
Required only to the extent necessary for account, contract, communications and regional controls. |
Identity-assurance |
Age/eligibility result; email-control event; wallet signature result; provider verification token or match result; limited identity attributes where expressly required. |
Prefer tokens, pass/fail results and partial identifiers over government-ID copies. |
Wallet and blockchain |
Public wallet address; chain/network; transaction identifiers and metadata; balances; asset and protocol interaction patterns; wallet-control evidence; risk and data-quality flags. |
Public data remain Personal Data when linkable; profiles and Scores are held off-chain. |
Exchange and financial source |
Provider/exchange identifier; account and balance data; transaction history; asset positions; deposits/withdrawals; account age; cash-flow and other authorised read-only fields. |
Scopes are disclosed before connection; no trading or withdrawal authority. |
Traditional and alternative financial |
Income, liabilities, payments, repayment or affordability-related information where supplied by an approved source and necessary for the configured use. |
Only fields documented in the product schedule and relevant to the stated purpose. |
Scores and inferences |
Score; range; principal factors and reason codes; confidence/data-quality indicators; segment or risk classification; model version; generated-at/data-cut-off/valid-until; status; history and dispute state. |
Derived data and inferences are Personal Data when linked to an individual. |
Sharing and recipient |
Named institution; purpose; scope; one-time/continuing access; authorisation version; expiry; revocation; recipient access log; sharing receipt. |
Used to execute and evidence user-directed sharing and enforce purpose limits. |
Technical, device and security |
IP address; device/browser; operating system; app version; session and authentication events; API identifiers; logs; fraud/abuse signals; vulnerability and incident data. |
Used for service operation, security, audit and abuse prevention. |
Commercial and support |
Order, subscription, invoice and payment metadata; contract; demo request; support ticket; communications; survey and feedback. |
Payment-card details are normally processed by the payment provider, not retained by ScoreID. |
Preferences and consents |
Terms version; consent or opt-out choice; marketing channel; cookie choice; timestamp; source interface; withdrawal and suppression record. |
Kept separately by purpose; service use is not conditional on optional marketing consent. |
Compliance and rights |
Rights request; identity-verification evidence; complaint; litigation hold; regulatory correspondence; audit and permissible-purpose certification. |
Restricted access and retention based on legal and accountability needs. |
5. Sources of personal data
We collect information directly from individuals and authorised Customer representatives when they create an account, request a Score, connect a source, direct sharing, communicate with us, exercise a right or configure an integration. We obtain information indirectly from wallets, exchanges, financial institutions, data aggregators and identity-assurance providers that the individual or Customer authorises.
We may also obtain Personal Data from public blockchain networks and explorers; lawfully accessible public or commercial sources; Institutional Customers using the API; service providers supporting hosting, security, communications and analytics; and our own systems through scoring, logging, model monitoring, support and misuse-prevention activity.
When data are not obtained directly, the interface or this Notice describes the categories and source. Where Article 14 GDPR requires individual notice, we provide it within the statutory period and at the latest at first communication or disclosure, unless a lawful exception applies. Public availability is not treated as a general exception from transparency or purpose limitation.
6. Purposes and legal bases
Where we rely on legitimate interests, we document the purpose, necessity and balance against individual rights, considering the sensitivity of financial and on-chain data, reasonable expectations, relationship, impact and safeguards. Individuals may request information about the relevant balancing assessment. Our interests do not override rights merely because processing is commercially useful.
Contract necessity is used only where processing is objectively necessary to provide the feature requested by the individual, not merely because processing is mentioned in terms. Consent is used only where there is a genuine choice, is specific and informed, and can be withdrawn as easily as it was given. Withdrawal does not affect processing already lawfully undertaken and does not prevent processing supported by a different lawful basis.
Purpose |
Data generally involved |
EEA/UK legal basis |
|---|---|---|
Create and administer an account; authenticate; provide requested features |
Account, contact, authentication, technical and preference data. |
Performance of a contract or steps requested before contract; legitimate interests for proportionate security controls. |
Connect a wallet, exchange or other source at the user’s request |
Connection metadata, provider authorisation, account/wallet and imported source data. |
Performance of the requested service; consent only where a separate law specifically requires it; legitimate interests for security. |
Generate, display and explain a requested Score |
Imported source data, on-chain data, derived features, Model outputs and status metadata. |
Performance of the requested scoring service; legitimate interests for integrity, validation and limited quality monitoring; additional safeguards where profiling is high risk. |
Execute user-directed disclosure to a named institution |
Score/data scope, recipient, purpose, authorisation and access logs. |
Performance of the user’s sharing instruction and, where required, consent; legal obligation or legitimate interests for evidence and abuse prevention. |
Provide institutional dashboard/API services |
Customer users, submitted data, Outputs, access logs, commercial and support data. |
Contract and legitimate interests for B2B administration; processor activity where performed solely on Customer instructions. |
Security, fraud and misuse prevention |
Account, device, IP, authentication, access, anomaly, connection and incident data. |
Legitimate interests in protecting individuals, customers and systems; legal obligations where applicable. |
Data quality, model validation, bias and performance monitoring |
Pseudonymised Input Data, Scores, outcomes where lawfully provided, error and drift metrics. |
Legitimate interests in accurate, fair and safe services, subject to necessity/balancing and safeguards; consent or another basis if required for a distinct research purpose. |
Develop or materially improve a Model |
Minimised, pseudonymised or anonymised datasets; feature and performance information. |
A separately documented lawful basis following compatibility, necessity, fairness and DPIA assessment; not automatically contract necessity. |
Support, complaints, disputes and rights |
Communications, Score history, relevant source and decision records, identity-verification evidence. |
Contract; legal obligation; legitimate interests in resolving issues and legal claims. |
Billing, accounting, audit and legal compliance |
Commercial, invoice, payment metadata, contracts, access and compliance records. |
Contract; legal obligation; legitimate interests in governance and defence of claims. |
Product analytics and reliability |
Minimised usage, device, performance and error data. |
Consent for non-essential cookies/SDKs where required; limited legitimate interests for essential operational telemetry. |
Email, SMS and push marketing |
Contact, channel, preference, consent and engagement information. |
Consent where required; limited legitimate interests only where law permits an existing-customer communication and always subject to opt-out. |
7. Whether information is required
Fields marked as required are necessary for the stated account, source connection, regulatory or contractual purpose. If required information is not provided, we may be unable to create the account, verify control of a source, generate a Score, execute sharing or comply with law. Optional fields and marketing permissions are identified separately.
We apply data minimisation. Country or region is preferred over full address unless identity matching, jurisdictional eligibility, invoicing or another documented need requires more. Gender and protected traits are not collected as ordinary production-scoring inputs. We maintain or require a feature register documenting each material input’s purpose, source, quality, predictive relevance, discrimination risk, retention and correction route.
8. Connected wallets, exchanges and financial sources
Before a connection is initiated, the interface or provider authorisation screen identifies the provider, requested permission scopes, categories to be imported, intended purpose, refresh frequency, expected duration, token handling and disconnect controls. Connections are designed to be read-only. ScoreID does not request authority to trade, transfer or withdraw assets unless a separately approved service expressly requires and discloses that capability; the current scoring service does not require it.
An exchange or aggregator may act as an independent controller for its own authorisation and account services and as a processor or subprocessor for the data it transmits on our behalf. Its privacy information may apply. We store access tokens only as necessary, protect them with access and secrets-management controls, and revoke or delete them after disconnection in accordance with technical and legal requirements.
A provider connection or wallet signature demonstrates technical access or control at a time; it does not establish legal ownership or civil identity. Account and wallet attribution can be wrong or shared. We use proportionate matching and quality controls and provide a challenge route.
9. Public blockchain data
Public wallet addresses, transaction metadata, event logs, smart-contract interactions and related traces can be Personal Data. Pseudonymity is not anonymity. We do not intentionally publish an individual’s Score, identity, reason codes, account data or financial profile to a public blockchain. Such information is stored off-chain under controlled access.
We process public-chain data only where necessary and proportionate to a documented scoring, verification, security or dispute purpose. We evaluate whether public-chain access is required, minimise the period and scope queried, avoid storing transaction payload content that is not relevant, and seek to filter data that could reveal special-category or protected traits. Plain-text personal data are not written on-chain by ScoreID.
Public blockchains are independently replicated and may involve nodes worldwide. ScoreID cannot erase or change an underlying public transaction and does not control the chain. We can, where a right applies, correct the association or interpretation in our systems, restrict use, delete off-chain profiles and cease future collection. Our blockchain processing and architecture are assessed in the relevant DPIA in light of EDPB Guidelines 02/2025.
10. Scoring, profiling and meaningful information about the logic
Score generation involves Profiling because financial, behavioural, exchange, alternative and on-chain signals are evaluated to assess or predict aspects of financial reliability or risk. Depending on the product, the Model may use rules, statistical methods or machine learning. The exact model card identifies the intended purpose, score range, main input groups, principal factor logic, data cut-off, version, validation and material limitations.
At a meaningful level, the process generally: (i) verifies and normalises authorised data; (ii) derives defined features such as account history, activity consistency, asset/liquidity patterns, payment or cash-flow indicators and data-quality measures; (iii) applies the versioned Model; (iv) maps the result to a score range or classification; and (v) produces principal positive and negative reason factors. The relative influence of categories varies by product, model and available data.
The significance is that a Score may inform how an institution assesses an individual, but it does not guarantee a product or outcome. Potential consequences can include further review, a request for more information, or—only in an approved and legally compliant decision workflow—an effect on approval, limits, pricing or access. The Score screen and sharing receipt identify the intended use and responsible recipient.
We do not withhold all explanation merely by invoking trade secrets. We may protect source code, security details and model parameters while still explaining the actual principal factors, data categories, limitations, Score status and how to contest inaccurate information.
11. Automated decisions and safeguards
ScoreID does not authorise an Institutional Customer to use a Score as the sole or determinative basis for a decision producing legal or similarly significant effects unless the use is expressly approved, a valid Article 22 GDPR exception or other legal basis applies, and required safeguards are implemented. A nominal human sign-off that routinely confirms the Score is not meaningful human involvement.
Where ScoreID itself makes, or the Score generation itself constitutes, an automated decision within Article 22 because a recipient attributes a determining role to it, the responsible controller will identify the permitted legal ground and provide suitable measures. These include the right to obtain human intervention, express a point of view, contest the decision, correct data and receive meaningful information about the logic and consequences.
Institutional Customers remain responsible for their final decision, decision notice and review channel. We contractually require them to consider other relevant information, ensure reviewers are trained and authorised to change the outcome, avoid automation bias and protected-trait proxies, and report material misuse. ScoreID may suspend an integration that lacks safeguards.
12. AI-system transparency and governance
If a Model qualifies as an AI system under Regulation (EU) 2024/1689 and is intended to evaluate the creditworthiness of natural persons or establish their credit score, it is classified as a high-risk AI system, other than a system used for detecting financial fraud. Profiling of natural persons prevents reliance on the limited Article 6(3) non-high-risk derogation. ScoreID assesses and documents its role and classification per product and intended use.
For a high-risk system, the applicable documentation supports risk management, data governance, technical documentation, automatic logs, deployer information, human oversight, accuracy, robustness, cybersecurity, quality management, conformity assessment, registration, post-market monitoring and incident reporting. Relevant personnel receive AI literacy and role-appropriate training.
A Customer using a high-risk system must follow instructions, ensure input relevance, assign competent human oversight, monitor operation, retain logs under its control for the required period, complete required data-protection and fundamental-rights impact assessments, notify affected persons where required and report serious incidents or material anomalies. Individuals affected by a qualifying significant decision may request a clear and meaningful explanation of the AI system’s role and main elements of the decision.
13. Recipients and disclosures
We do not sell Personal Data for money. We do not permit Scores or FCRA-regulated information to be sold, used for unrelated advertising or reused for an incompatible purpose. Whether a cookie/SDK disclosure constitutes “sale”, “sharing” or targeted advertising under a U.S. state law depends on the actual vendor and configuration and is addressed in the U.S. State Privacy Notice and live privacy controls.
Recipient category |
Why data may be disclosed |
Safeguards / role |
|---|---|---|
Named institution selected by the User |
Execute a specific sharing instruction or approved application workflow. |
Recipient, purpose, scope and period shown before disclosure; institution normally becomes independent controller. |
Institutional Customer |
Provide contracted dashboard/API processing and support. |
Role allocation, purpose limits, DPA where ScoreID acts as processor, access and audit controls. |
Cloud, database and infrastructure providers |
Host, transmit, back up and secure the Services. |
Contract, confidentiality, security, subprocessor oversight and transfer mechanism. |
Wallet, node, exchange and data-connection providers |
Retrieve or verify authorised data and network state. |
Minimum scopes; provider terms; role assessment; no seed phrase/private key. |
Identity-assurance, communications and support providers |
Verify configured attributes, send service messages and provide support. |
Purpose limitation, data minimisation and processor/controller role allocation. |
Analytics and cookie vendors |
Measure performance or optional engagement. |
Non-essential access subject to consent where required; live CMP and vendor inventory. |
Professional advisers, auditors and insurers |
Governance, transactions, claims and legal advice. |
Need-to-know, professional/confidentiality obligations and minimisation. |
Authorities, courts and regulators |
Comply with binding law, legal process, supervision or protect rights and security. |
Validate authority and scope; challenge overbroad requests where appropriate; log disclosure. |
Corporate transaction parties |
Evaluate or complete financing, merger, sale or reorganisation. |
Confidentiality, due-diligence minimisation and continued protection. |
14. User-directed sharing
Before a Score or data are shared, the User is shown the named recipient, stated purpose, categories or Output, one-time or continuing nature, access period, whether future Scores are included, and revocation controls. We record the instruction and access and provide a durable sharing receipt or equivalent account history.
Revocation prevents future access where technically and legally possible but cannot recall information already received or prohibit a recipient’s lawful retention for a transaction, dispute, regulatory file or claim. The recipient must provide its own notice for independent use. Users may view sharing history and report suspected misuse.
15. International transfers
We seek to process EEA Personal Data in the EEA where reasonably practicable. Some service providers or recipients may be located in, or remotely access data from, countries outside the EEA, United Kingdom or Switzerland. A transfer occurs only under an applicable mechanism and after role, location and risk assessment.
Depending on the destination, we rely on an adequacy decision, the European Commission Standard Contractual Clauses (Decision 2021/914) using the correct module, the UK International Data Transfer framework, another lawful derogation used restrictively, or another legally recognised mechanism. We conduct transfer impact assessments and apply supplementary contractual, technical and organisational measures where necessary, including encryption, access restrictions, minimisation and government-request procedures.
The current Subprocessor and International Transfer List must identify provider, service, processing location, role and transfer mechanism. Individuals may request relevant information and a copy of applicable safeguards, subject to redaction of confidential or security-sensitive details. Public-blockchain access can involve global nodes; we minimise what ScoreID discloses to a chain and do not write personal profiles or Scores on-chain.
16. Retention
We retain Personal Data only for the period necessary for the stated purpose, taking account of Score freshness, account term, dispute and rights needs, security, model accountability, legal limitation periods, sector recordkeeping and valid legal holds. Retention does not mean that a historical Score remains authorised for current decision use.
The indicative periods below do not postpone or override a valid erasure request. Where erasure applies, ScoreID deletes or irreversibly anonymises the relevant Personal Data in active production systems within the one-month rights-response period. Data may be retained after that period only where an Article 17(3) GDPR exception or another applicable legal exception requires or permits retention. In that case, ScoreID retains only the minimum record and the minimum identity linkage necessary to prove whose record it is, keeps it in a restricted legal-retention archive, does not use it for a new Score or decision, and deletes it when the retention ground ends.
Record |
Operational rule / indicative maximum |
Rationale |
|---|---|---|
Active Score and current explanation |
Until the stated valid-until date, supersession or an applicable erasure request, whichever occurs first. The product must set a validated validity period; an operational validity period never postpones an applicable erasure request. |
Provide current view and approved sharing. |
Historical Score, factor snapshot and model version |
Normally up to 24 months after supersession, but deleted within the rights-response period where a valid erasure request applies. Longer retention is permitted only for a documented legal or regulatory obligation, a specific dispute or claim, or a valid legal hold. |
Auditability, correction, model validation and claims. |
Raw imported wallet/exchange data |
Minimised and deleted or irreversibly anonymised promptly, and ordinarily no later than thirty (30) calendar days after Score generation or source disconnection, unless needed for an active connection, contracted refresh, documented dispute or legally permitted retention. A valid erasure request remains subject to the one-month rights-response period. |
Reduce financial-data exposure while retaining necessary evidence. |
Connected-source token |
For the active connection; revoked/deleted promptly after disconnection subject to provider and backup cycle. |
Enable authorised retrieval only. |
Account and contract data |
Account term plus normally up to 24 months; invoices and legally required records for the statutory period. |
Account, support, audit and legal obligations. |
Sharing authorisation and recipient-access log |
Normally 24 months after access/revocation; longer if part of a regulated decision, dispute or legal hold. |
Evidence of recipient, purpose and access. |
Authentication and security logs |
Normally 12 months; longer for active incident, threat investigation or documented security need. |
Security, abuse prevention and forensic investigation. |
Support, complaint, privacy-right and Score dispute file |
Closure plus normally 24 months, or applicable legal limitation/recordkeeping period. |
Demonstrate response and defend rights. |
Marketing consent and suppression |
Consent evidence while relied upon plus accountability period; suppression retained as necessary to honour opt-out. |
Demonstrate consent and prevent re-contact. |
Cookie consent record |
Normally 13–24 months or applicable national period; refreshed on material change. |
Demonstrate and remember choice. |
Identity-document copy |
Avoided; if exceptionally required, deleted promptly after verification and any mandatory retention period. |
Data minimisation and identity assurance. |
Backups |
Isolated from ordinary use upon production deletion and overwritten through a documented cycle no later than ninety (90) days after production deletion. This backup cycle does not extend the one-month rights-response period: backup data are not used or restored to ordinary production, and any disaster-recovery restoration reapplies the deletion before ordinary use. |
Resilience while preventing restoration to active use. |
17. Accuracy, correction and score disputes
We take reasonable steps to keep data accurate and, where necessary, current for the purpose. Because providers, public chains and Customer submissions can be incomplete or incorrectly attributed, we display data cut-off, source categories, quality indicators and Score status. A new Score supersedes the previous Score for current use.
Individuals may challenge source attribution, factual data, duplication, technical processing, Score status or the principal-factor explanation. We acknowledge the request, restrict or mark the affected Score where appropriate, investigate relevant sources and model execution, and correct or recalculate where an error is verified. We inform recipients of correction where required and reasonably possible.
An institution responsible for a decision must separately review its own data and decision. We may forward a dispute to the responsible controller or source and coordinate, but we do not prevent an individual from exercising rights directly against that organisation.
18. Your EEA/UK privacy rights
Rights are not absolute. An exemption may apply for the rights and freedoms of others, confidential information, legal claims, security, regulatory records or another statutory ground. We explain any material refusal and available complaint route. Direct-marketing objections are honoured without balancing.
- access Personal Data and receive information about purposes, categories, sources, recipients, retention and qualifying automated decision-making;
- rectify inaccurate data and complete incomplete data, taking account of the purpose;
- erase data where the legal conditions are met, recognising that public-chain data outside ScoreID’s control cannot be erased by ScoreID;
- restrict processing while accuracy, objection or lawfulness is assessed;
- receive data provided by the individual in a structured, commonly used and machine-readable format and, where technically feasible, transmit it to another controller when portability applies;
- object at any time to direct marketing and object, on grounds relating to the individual situation, to processing based on public task or legitimate interests;
- withdraw consent at any time without affecting prior lawful processing;
- not be subject to a qualifying solely automated decision and obtain the safeguards described in Section 11; and
- lodge a complaint with a competent supervisory authority and seek a judicial remedy.
19. Exercising rights and verification
Requests may be sent to hello@scoreid.com or submitted through the account rights center where available. Please identify the account, relevant Score or connection and the right requested. We respond without undue delay and, where GDPR applies, within one month after receipt. If a valid erasure request is granted, deletion or irreversible anonymisation from active production systems is completed within that same period. For complex or numerous requests, the period may be extended by up to two further months only where permitted by GDPR; we notify the individual within the first month and explain the reasons for the extension. Isolated backup copies are handled under Section 16 and do not remain available for ordinary use.
We verify identity proportionately to the request and sensitivity. We may use account authentication, email control, source knowledge or limited additional evidence. We do not request a full identity document where a less intrusive method is sufficient. If ScoreID acts solely as processor, we inform and assist the responsible Customer rather than independently deciding the request unless authorised or legally required.
Requests are generally free. We may charge a reasonable fee or refuse only where a request is manifestly unfounded or excessive and law permits. Authorised representatives must provide valid authority, and we may verify the individual directly where permitted.
20. Complaints and supervisory authorities
We encourage individuals to contact us first so we can investigate. EEA individuals may complain to the supervisory authority in the Member State of habitual residence, place of work or alleged infringement. ScoreID’s lead supervisory authority, where the one-stop-shop applies, is expected to be the Dutch Data Protection Authority (Autoriteit Persoonsgegevens), subject to confirmation of ScoreID’s main establishment and processing arrangements.
A complaint to ScoreID does not limit the right to contact an authority, court, consumer body or other competent regulator. We do not retaliate or discriminate because an individual exercises a right.
21. Marketing, push notifications and consent
Marketing permission is separate from Terms acceptance, service processing and user-directed sharing. Email marketing, SMS marketing, promotional push notifications and third-party/partner marketing use separate, specific and unticked controls where consent is required. Refusal or withdrawal does not prevent use of core Services.
Service communications—including OTP, security alerts, legal notices, source-connection messages, Score-ready/status notices and support responses—are not marketing and may be sent as necessary. We do not add promotional content that changes the primary nature of a transactional message. Every marketing channel includes an effective withdrawal route; suppression records may be retained to honour the choice.
Consent records include the text and document version, purpose, channel, timestamp, source interface, account/device evidence and later withdrawal. Consent is refreshed when the purpose, vendor or processing materially changes.
22. Cookies and similar technologies
We use cookies, local storage, pixels, software development kits and similar technologies as described in the Cookie Policy and live consent manager. Strictly necessary technologies support authentication, security, consent storage and requested functionality. Non-essential analytics, personalisation and advertising technologies are not activated before valid consent in jurisdictions requiring it.
The consent interface offers accept and reject options with comparable ease, granular purpose/vendor choices and a persistent settings control. It records and honours withdrawal. U.S. universal opt-out signals, including Global Privacy Control, are recognised where legally required. The live inventory—not a generic policy description—identifies each active technology, provider, purpose, category, duration and relevant transfer.
23. Security
We use measures appropriate to the risk, including role-based access and least privilege; multi-factor authentication for privileged access; encryption in transit and where appropriate at rest; secrets and key management; environment separation; logging and anomaly detection; secure development and change control; vulnerability management; backup and recovery; incident response; personnel confidentiality; vendor due diligence; and periodic testing.
We maintain procedures to assess a Personal Data Breach and notify the competent authority and affected individuals where legally required. No system is completely secure. Individuals must protect devices and accounts, never share seed phrases or private keys, and report suspected compromise promptly.
24. Children
The individual Services are not directed to persons under 18 and we do not knowingly provide personal scoring Services to minors. If we learn that a minor’s Personal Data were collected contrary to this Notice, we take reasonable steps to delete or restrict it. Institutional Customers must not submit children’s data unless an expressly approved service, valid legal basis, age-appropriate notice and heightened safeguards apply.
25. Corporate transactions and legal claims
We may disclose or transfer relevant data in a financing, merger, acquisition, reorganisation, insolvency or sale of business, subject to confidentiality, due-diligence minimisation and continued legal protection. If a transaction materially changes the controller or purpose, affected individuals receive notice and any required choice before incompatible processing.
We may preserve and use information necessary to establish, exercise or defend legal claims, comply with a binding request or maintain a legal hold. Access is restricted and the information is not returned to ordinary product use merely because it is retained.
26. United States state privacy notice
Residents of applicable U.S. states may have rights to confirm processing; know and access categories and specific pieces of Personal Information; correct; delete; obtain portability; opt out of sale, sharing, targeted advertising and Profiling in furtherance of decisions producing legal or similarly significant effects; limit certain uses of sensitive Personal Information; appeal a refusal; and use an authorised agent. Rights and exceptions depend on the state and may apply to particular data or activities rather than the whole entity.
The categories collected in the preceding twelve months are described in Section 4 and Annex A: identifiers; account and commercial information; internet/device activity; financial and wallet information; public blockchain records; inferences and Scores; precise location only if a feature expressly requires it; communications; and compliance records. Sources, purposes and recipient categories are described in Sections 5, 6 and 13. We retain information under Section 16.
We do not sell Personal Information for money. If an analytics or advertising configuration constitutes “sale”, “sharing” or targeted advertising under applicable law, the live privacy controls identify it and provide the required opt-out. We process Global Privacy Control and other recognised universal opt-out mechanisms where required. We do not use sensitive Personal Information to infer characteristics or beyond permitted purposes without the consent or limitation right required by law.
Requests may be sent to hello@scoreid.com. We will verify them proportionately, respond within the applicable period (often 45 days), explain a refusal and provide an appeal process where required. We do not discriminate for exercising privacy rights. Before using Profiling or automated decision technology for a significant decision, the responsible controller must provide required pre-use information, impact assessment, explanation, opt-out or human-review route as applicable.
27. FCRA-related processing
A Service not expressly designated in a signed product schedule as FCRA-Enabled must not be used for United States credit, insurance, employment, housing or another eligibility purpose regulated by the Fair Credit Reporting Act. User authorisation to share information does not by itself remove FCRA obligations or convert a non-compliant product into an FCRA-Enabled Service.
If ScoreID introduces an FCRA-Enabled Service, individuals will receive a separate U.S. Consumer Rights and Dispute Notice explaining file disclosure, sources and recipients, accuracy procedures, fraud and identity-theft rights, security freezes where applicable, and free dispute/reinvestigation. Institutional users will be subject to permissible-purpose certification, access controls, adverse-action and risk-based-pricing obligations, recordkeeping and audit. FCRA exemptions under state privacy laws are applied only to qualifying data or activity and do not automatically exempt website, account, cookie or marketing processing.
28. Changes and contact
We may update this Notice to reflect changes in law, Services, Models, sources, recipients or practices. Material changes are communicated in advance where required, and consent is requested again where the legal basis or scope requires it. The Last Updated date and version identify the applicable text; prior versions are retained in the Legal Center or made available on request.
Questions, rights requests and complaints may be sent to ScoreID B.V. at hello@scoreid.com. Before publication, the Legal Center must add the verified registered address, KvK number, privacy/DPO contact if applicable, and current Subprocessor and International Transfer List.
Annex A. Detailed data and processing matrix
Processing activity |
Source |
Output / disclosure |
Profiling or ADM |
Primary control |
|---|---|---|---|---|
Account signup and email verification |
Individual |
Account and authentication record |
No |
Minimal fields; Terms record; Privacy Notice; OTP limited to email control. |
Wallet connection |
Individual, wallet and public chain |
Verified control result and imported public-chain indicators |
May feed Profiling |
Read-only; source notice; no private key; off-chain profile. |
Exchange connection |
Individual and authorised provider |
Imported financial/transaction indicators |
May feed Profiling |
Scope screen; token security; disconnection; minimum fields. |
Score generation |
Connected Sources, public chain, Customer and derived features |
Score, factors, model/status metadata |
Yes; may be Article 22-relevant depending on use |
DPIA; explanation; data quality; status/freshness; contest and human review. |
User-directed sharing |
User and existing Score record |
Named recipient receives specified Score/data |
Recipient may use in a decision |
Recipient/purpose/scope/duration; durable receipt; revocation; access log. |
Institutional API |
Customer and ScoreID systems |
Output to authorised institutional user |
Potentially significant |
Role allocation; purpose certification; human oversight; logs; audit; prohibited uses. |
Model validation |
Pseudonymised production or approved validation data |
Aggregate performance, fairness, drift and error metrics |
Model governance |
Separate purpose/basis; minimisation; controlled access; DPIA and no individual adverse use. |
Marketing |
Individual and communication provider |
Promotional communication and suppression record |
No decision Profiling unless separately disclosed |
Separate channel consent/opt-out; no bundling. |
Annex B. Score explanation and rights workflow
- The Score screen identifies the Score, range and direction; generated-at and data cut-off; valid-until and status; Model version; intended purpose; main data-source categories; and principal favourable and adverse factors.
- The individual can inspect connected sources and sharing history, disconnect future access, correct account data, challenge attribution or material input error, and request a human-readable explanation.
- A material challenge causes the Score to be marked Disputed or use-restricted where appropriate while relevant source and processing records are investigated.
- Verified errors are corrected and, where appropriate, the Score is recalculated. Required recipients are notified of correction. The prior Score remains Historical for audit and is not treated as current.
- Where an institution made the decision, ScoreID routes or coordinates the request while preserving the individual’s right to address the institution directly. The institution remains responsible for its decision explanation and review.