API AND INSTITUTIONAL USE TERMS
Supplemental terms for institutional integration with ScoreID APIs, dashboards, SDKs and scoring Outputs.
Document control |
Details |
|---|---|
Legal entity |
ScoreID B.V., the Netherlands |
Last updated |
16 July 2026 |
Status |
Contractual 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. Scope, incorporation and precedence
These API and Institutional Use Terms (“API Terms”) govern access to ScoreID endpoints, software development kits, keys, webhooks, dashboards, developer tools, documentation, data feeds and responses (collectively, the “API”). They supplement the Terms of Service, applicable order form, master agreement, Data Processing and Role Allocation Addendum (“DPA”) and product/model documentation.
Capitalised terms not defined here have the meanings in those documents. The signed order form controls approved product, territory, users, volumes and commercial terms; the DPA controls processor obligations; a product/model schedule controls intended purpose and technical characteristics; and these API Terms control integration and institutional use. Mandatory law prevails.
2. Definitions and approved integration
“Customer Application” means the Customer-controlled service through which the API is accessed or an Output is used. “Production” means live processing involving real individuals or operational decisions. “Permitted Purpose” means the specific purpose, product, population, territory and decision stage approved in the order form. “High-Impact Decision”, “Output”, “Score”, “Model” and “FCRA-Enabled Service” have the meanings in the Terms of Service.
The approved integration comprises only the endpoints, fields, scopes, environments and use cases documented by ScoreID. A proof of concept, sandbox or demo is not approved for Production or individual decisions. Customer must complete the certification in Annex 2 and obtain written production approval before live use.
3. Licence and documentation
Subject to the Agreement and payment, ScoreID grants Customer a limited, non-exclusive, non-transferable, non-sublicensable and revocable right during the term to access the API solely for the Permitted Purpose. Customer may expose approved functionality to authorised end users through the Customer Application but may not resell, white-label, redistribute or make the API independently available without written permission.
Customer must follow current technical documentation, security requirements, model instructions and deprecation notices. Customer is responsible for its integration, user interface, mapping, decision rules and communications. It must not remove or obscure status, freshness, limitation, reason, source or attribution fields that are necessary for lawful and accurate interpretation.
4. Credentials, environments and security
API keys, tokens and secrets are confidential and specific to the approved Customer, environment and purpose. Customer must store them in an approved secrets-management system; apply least privilege; segregate development, test and Production; rotate on compromise; restrict administrator access; validate TLS and webhook signatures; monitor unusual calls; and promptly revoke access for departing personnel.
Customer must not embed secret credentials in public client code, repositories or logs; share credentials across unrelated entities; route data through an unapproved system; disable certificate validation; or use Production Personal Data in test except where expressly approved and protected. Customer is responsible for activity under credentials until it notifies ScoreID and ScoreID has a reasonable opportunity to disable them.
ScoreID may require allowlisting, mutual TLS, IP restrictions, multi-factor administration, penetration-test evidence or other proportionate controls. Customer will notify ScoreID without undue delay of suspected credential compromise, unauthorised access, vulnerability or security incident.
5. Purpose certification and end-user authority
Before access, Customer must certify the Permitted Purpose, legal entity, jurisdiction, product, end-user population, decision stage, lawful basis, retention, human-review process and whether the use concerns credit, insurance, employment, housing or another regulated eligibility purpose. Certification must be accurate and renewed after material change.
Customer may submit or retrieve Personal Data only where it has authority and a lawful basis, has provided required notice and, where applicable, has obtained a valid and specific user instruction identifying recipient, purpose, data scope and duration. User authorisation is not a substitute for another legal basis, regulatory permissible purpose or statutory notice.
Customer must not use one person’s credentials, authorisation or data to access another person’s file; extend the purpose after collection; or permit a third party to use an Output without separate approval. Customer must preserve evidence of notice, authorisation and purpose and produce it on reasonable request.
6. Data submission and minimisation
Customer will submit only fields documented for the approved endpoint and necessary for the Permitted Purpose. Data must be adequate, relevant, accurate, current and lawfully obtained. Customer is responsible for mapping identifiers to the correct person and for promptly correcting known errors.
Unless expressly approved, Customer must not submit wallet private keys or seed phrases; trading/withdrawal credentials; full identity documents; government identifiers; special-category data; criminal-offence data; children’s data; precise location; or protected traits such as race, religion, health, sexual orientation or political views. Gender is not an ordinary scoring input. Full address is used only where country/postcode is insufficient for a documented matching or regulatory need.
Sensitive information used solely for fair-lending or bias monitoring must be technically and organisationally separated from production scoring, access restricted and supported by a valid legal condition and assessment. It must not influence an individual Output.
7. Output schema, status and freshness
API responses for a Score use the applicable fields described in Annex 1, including score or classification, range, generated_at, data_cutoff, valid_until, model_version, status, principal reason factors, data-quality/coverage indicators and intended-use information. Customer must retain or be able to reconstruct the version and status used in a material decision.
Unless a product schedule states a shorter validated period, a Score is current for no more than ninety (90) days. A High-Impact Decision may require materially fresher data. An approved U.S. decision-use product may specify a maximum thirty-day freshness period. Customer must not hard-code a longer period or ignore valid_until.
A new Score supersedes the prior Score immediately for current use. Customer integrations must honour Active, Expired, Superseded/Historical, Disputed, Suspended and Refresh Required statuses. Historical records may be retained for audit and dispute but must not be silently reused or represented as current.
8. Score interpretation and explanations
Outputs are probabilistic and dependent on available data, attribution, Model version and intended purpose. Customer must interpret them with disclosed range, status, factors, quality indicators and limitations and consider other relevant information. A Score is not legal identity verification, KYC/AML clearance, source-of-funds proof, fraud determination or guarantee of approval, repayment or conduct.
Customer must map reason information to the actual factors considered in its own decision and provide specific, accurate explanations required by law. Generic statements such as “minimum score not met” are not sufficient where the law requires principal reasons. Customer must not substitute a post-hoc or model-agnostic explanation that does not reflect the actual decision process.
ScoreID may protect source code, model parameters and security-sensitive details while providing meaningful information about input categories, principal factor logic, significance, limitations and contest. Customer will protect model documentation as confidential but may disclose information legally required for an individual or regulator.
9. High-impact decisions and GDPR Article 22
Customer must not use an Output as the sole or determinative basis for a High-Impact Decision unless ScoreID has expressly approved the use, Customer has documented a valid legal ground and all applicable safeguards are in place. The fact that Customer nominally issues the final decision does not prevent Score generation from being automated decision-making where the Score in practice plays a determining role.
Where Article 22 GDPR or equivalent law applies, Customer will identify the applicable exception; provide meaningful information about logic, significance and envisaged consequences; implement the right to human intervention, expression of view and contest; and ensure that the reviewer has competence, information, authority and practical ability to change the outcome. Routine rubber-stamping is prohibited.
Customer will complete a DPIA before Production where required and provide ScoreID with relevant risk and mitigation information. Customer must monitor automation bias, false positives/negatives, protected-class proxy risk and actual outcomes. ScoreID may suspend use that is inconsistent with the approved human-oversight design.
10. EU AI Act provider/deployer allocation
For an API component qualifying as an AI system, the Parties will identify their factual roles under Regulation (EU) 2024/1689. Where ScoreID develops and supplies a Model under its name, ScoreID is generally provider and Customer using it in its process is generally deployer. An AI system intended to evaluate natural-person creditworthiness or establish a credit score is classified as high-risk, other than a system used for detecting financial fraud; a system performing profiling cannot rely on the Article 6(3) low-impact derogation.
ScoreID will provide required instructions, intended purpose, performance and limitation information, human-oversight measures, logging functionality and other provider documentation for an approved high-risk Service. Customer will: follow instructions; assign competent oversight; ensure input relevance; monitor operation; retain logs under its control for the legally required period and no less than six months where Article 26 requires; complete any Article 27 fundamental-rights impact assessment; inform affected persons where required; and report serious incidents and material malfunctions.
Customer must not remove safety/status controls, materially modify the system, change its intended purpose, retrain or fine-tune the Model, or place it on the market under Customer’s name without prior written approval. A Customer doing so may assume provider obligations and must complete all required conformity, registration, quality and post-market measures.
Customer will cooperate with ScoreID’s post-market monitoring, incident investigation, corrective action and authority requests. If Customer reasonably believes use may create a risk to health, safety or fundamental rights, it will suspend the affected use and notify ScoreID without undue delay.
11. EU consumer-credit and non-discrimination controls
Where Customer is a creditor or uses an Output in consumer credit, BNPL or a comparable assessment, it remains responsible for applicable creditworthiness, affordability, explanation and consumer-protection duties. The Score must not be represented as the entire legally required creditworthiness assessment. Customer must use necessary, proportionate, relevant and accurate information and must not use social-network data or special-category data where prohibited.
Customer will test its overall decision process for direct and indirect discrimination and unlawful proxy effects. Protected characteristics are not production inputs. Neutral-looking variables—such as geography, device, wallet patterns or transaction categories—must be assessed for economic relevance, predictive validity and disparate impact. Human reviewers must not introduce prohibited discrimination.
For a qualifying automated creditworthiness assessment under Directive (EU) 2023/2225 as implemented, Customer will provide human intervention, a clear explanation, the opportunity to express a view and a review of the assessment.
12. United States FCRA restriction
A Service not expressly designated in a signed product schedule as FCRA-Enabled must not be used as a consumer report or for a United States consumer’s eligibility for credit or BNPL, insurance, employment, housing, account review or another FCRA purpose; to set a credit limit or price; or to take adverse action. User consent or instruction can be a permissible purpose in some circumstances but does not remove FCRA coverage or cure an unauthorised product.
Customer must not market a non-FCRA-Enabled Output as a credit report, resell or redisclose it for eligibility, merge it into a consumer-report file, or ask ScoreID to supply it for an expected eligibility use. ScoreID may technically restrict U.S. decision use and will suspend access where certification, logs or marketing indicate an unauthorised purpose.
For a separately approved FCRA-Enabled Service, Customer must certify and maintain a permissible purpose; authenticate users; restrict use and redisclosure; retain records; provide required notices; support file disclosure and dispute/reinvestigation; accurately use Score information and principal factors; and comply with adverse-action, risk-based-pricing, Equal Credit Opportunity Act/Regulation B and state-law obligations. The product schedule will allocate additional duties.
13. U.S. state privacy and automated decision controls
Customer will determine which U.S. state privacy laws apply to its collection, Profiling and decisions and will provide required notices, rights and appeals. Where applicable, individuals must be able to opt out of Profiling in furtherance of decisions producing legal or similarly significant effects; receive pre-use information; access meaningful information about the technology and output; correct data; appeal; and obtain meaningful human review.
Customer will honour Global Privacy Control or other universal opt-out signals where applicable to its processing, obtain consent for sensitive data where required and complete state data-protection or automated-decision assessments. A data- or activity-specific FCRA/GLBA exemption must not be treated as an entity-wide exemption for account, website, marketing or cookie processing.
14. Prohibited uses
- any use outside the certified Permitted Purpose, product, territory, population or decision stage;
- unlawful surveillance, discrimination, redlining, exploitation or use of protected traits or unvalidated proxies;
- sole or determinative High-Impact Decision use without express approval and required safeguards;
- United States eligibility use of a non-FCRA-Enabled Service;
- sale, advertising reuse, incompatible secondary use, public disclosure or unauthorised redisclosure of personal Outputs;
- re-identification of de-identified data or linkage of identifiers for an unrelated profile;
- submission of private keys, seed phrases, malware, unlawfully obtained credentials or unapproved sensitive data;
- scraping, bulk extraction, credential sharing, rate-limit evasion or circumvention of security/status controls;
- reverse engineering or use of Outputs to create or train a competing model or unauthorised dataset, except where law prohibits restriction;
- misrepresentation that ScoreID made the final decision, guarantees approval, is a KYC provider/credit bureau for an undesignated Service, or certifies compliance; and
- use in weapons, unlawful law enforcement, social scoring, manipulation or another prohibited AI practice.
15. Privacy roles and DPA
Privacy roles are determined per processing activity. Customer is independent controller for its collection, decision, notice, lawful basis, retention, rights and regulatory duties. ScoreID may be independent controller for direct accounts, general Model governance, security, billing and legal compliance. ScoreID is processor only for activities performed solely on Customer’s documented instructions and identified in the DPA Annex 1.
Customer must not describe ScoreID as processor for all processing if ScoreID determines a separate purpose, and ScoreID will not recharacterise instructed processing solely to avoid processor obligations. Independent-controller sharing, processor processing and any genuine joint controllership follow the applicable DPA module.
16. Retention, deletion and rights cooperation
Customer will configure and apply retention appropriate to the purpose and law. It must not treat a Historical Score as current merely because it retains the record. Customer will delete or anonymise Personal Data and Outputs when the Permitted Purpose and legal retention need end and will ensure downstream recipients do the same.
Customer will provide ScoreID information and instructions needed to support access, correction, deletion, restriction, portability, objection, Score dispute and automated-decision rights. Where ScoreID acts independently, the Parties cooperate without preventing an individual from addressing either controller. Customer remains responsible for its decision explanation and review.
17. Monitoring, logging and audit
ScoreID may log Customer/account identifiers, endpoint, purpose code, subject pseudonymous identifier, timestamp, response status, Model version, Score status, rate-limit and security events to operate, secure and verify compliance. ScoreID does not use audit logs for unrelated advertising.
Customer will preserve required authorisation, decision, explanation, human-review and access records and will supply evidence on reasonable request. ScoreID may audit use, permissible purpose, integration controls and marketing claims on reasonable notice and may use automated controls to detect expired-score use, unusual volume, unauthorised purpose or credential misuse.
Customer will cooperate with privacy, AI Act, FCRA, fair-lending, security and regulator investigations. An audit is subject to confidentiality and proportionality and does not authorise access to another customer’s data or ScoreID trade secrets beyond legal necessity.
18. Incidents, model issues and corrective action
Customer will notify ScoreID without undue delay of a security incident, Personal Data Breach, material Output error, unexplained performance deterioration, discriminatory outcome, unauthorised decision use, serious incident or regulator complaint relating to the API. It will preserve evidence and suspend affected use where continued operation may cause harm.
ScoreID may investigate data lineage, Model version, logs, feature execution and Customer integration; mark Outputs Disputed or Suspended; correct or withdraw a Model or endpoint; require refresh; notify affected Customers; or instruct temporary cessation. Customer must implement corrective instructions and identify affected decisions and individuals where law requires.
The Parties will coordinate legally required authority or individual notices, while the Party with the legal obligation remains responsible. No corrective action or notification is an admission of liability.
19. Rate limits, availability and changes
Customer must comply with documented rate, concurrency, payload and storage limits and must implement retries, timeouts, circuit breakers and error handling. Unless an SLA states otherwise, the API is provided as available without guaranteed uptime or response time. Customer must not design a safety- or rights-critical process without appropriate fallback and manual continuity.
ScoreID may version, modify or deprecate endpoints and Models. Reasonable advance notice is provided for material breaking or intended-purpose changes where practicable. Urgent security, legal, data-source or fundamental-rights risk may require immediate change or suspension. Customer must test and validate material changes before Production and preserve the Model/version used for historical decisions.
20. Third-party dependencies
The API may depend on public blockchains, nodes, exchanges, data aggregators, identity providers and cloud services. Their availability, terms and data quality can change. Customer must account for incomplete, stale, reorganised or unavailable source data and must not represent third-party or public data as verified beyond the assurance actually performed.
ScoreID may replace or discontinue a dependency where necessary for legality, security, accuracy or viability and will use reasonable transition measures for a contracted material dependency. Third-party terms may apply and Customer must not cause ScoreID to breach them.
21. Intellectual property and feedback
ScoreID retains all rights in the API, Services, Models, methodologies, documentation, schemas, reason frameworks and improvements. Customer retains rights in data it lawfully submits and grants ScoreID the rights necessary to provide, secure and support the Service and comply with law.
Customer may not benchmark publicly, publish performance claims, disclose confidential documentation or use the API to infer Model parameters without written approval. Feedback may be used without restriction if it does not contain Customer confidential information or Personal Data.
22. Confidentiality
API credentials, non-public documentation, Model information, security materials, pricing, test results and each Party’s non-public business and personal data are confidential. They may be used only for the Agreement and disclosed only to personnel/advisers with a need to know and confidentiality obligations, subject to compulsory disclosure procedures in the Agreement.
23. Suspension and termination
ScoreID may throttle, suspend or terminate access where reasonably necessary for credential compromise, security risk, prohibited or unlawful use, missing lawful basis/permissible purpose, excessive load, non-payment, material regulatory/fundamental-rights risk or breach. Immediate action is permitted where delay may cause harm; otherwise ScoreID will provide notice and a reasonable opportunity to cure where practicable.
On termination, Customer stops calls and use of current Outputs, deletes credentials and returns/deletes data under the Agreement and DPA. Required historical decision/audit records may be retained with access restriction but must not be reused as current.
24. Warranties, liability and law
ScoreID warrants that the API will be provided with reasonable skill and care and substantially according to current documentation. Outputs remain probabilistic and time-sensitive and are not guarantees of identity, KYC, credit approval, repayment, compliance or an error-free decision. Disclaimers and liability limitations in the Agreement and Terms of Service apply, subject to mandatory law.
These API Terms are governed by Netherlands law and business disputes are subject to the competent courts of Amsterdam unless the Agreement states otherwise. The DPA/SCCs control data-protection and Restricted Transfer disputes as required.
Annex 1. Required API fields and status handling
Field / control |
Requirement |
Customer handling |
|---|---|---|
score / classification and range |
Actual Output and interpretation range/direction. |
Display/use only for documented intended purpose; do not imply guarantee. |
generated_at |
Time the Output was produced. |
Preserve for audit and decision timing. |
data_cutoff |
Latest point represented by material Input Data. |
Assess staleness and missing recent events. |
valid_until |
End of approved current-use period. |
Block new current decision after expiry. |
model_version |
Version producing the Output. |
Preserve; validate material changes; do not silently compare incompatible versions. |
status |
Active, Expired, Superseded, Disputed, Suspended or Refresh Required. |
Enforce status; Historical/Disputed/Suspended not current. |
reason_factors |
Principal favourable/adverse factors actually produced. |
Map only to actual decision reasons and provide specific explanation where required. |
data_quality / coverage |
Material completeness, attribution or source limitations. |
Route low-quality or anomalous cases to review; do not treat absence as adverse without validation. |
intended_use / purpose_code |
Approved product and purpose. |
Reject mismatched use and preserve purpose certification. |
human_review_required |
Flag for review under product/law rules. |
Route to authorised reviewer with power to change outcome. |
Annex 2. Customer go-live certification
- Customer legal entity, product, territories, user population and Permitted Purpose are complete and accurate.
- The Service is not used for a U.S. FCRA eligibility purpose unless the order form expressly designates it FCRA-Enabled.
- Controller/processor roles, Privacy Notice, lawful basis, source authorisation and rights channels are documented.
- DPIA and, where applicable, AI Act fundamental-rights, fair-lending and state automated-decision assessments are approved.
- The integration enforces status, valid_until, model_version, reason and quality fields and preserves required logs.
- A competent human-review process exists for High-Impact Decisions; reviewers are trained and can change outcomes.
- Decision/adverse-action explanations reflect actual factors and responsible Customer contact details.
- Security, credential, incident, deletion, access-review and business-continuity controls have been tested.
- Marketing and UI claims accurately describe verification, availability, outcome and Score limitations.
- A responsible Customer executive has approved Production use and will notify ScoreID before material change.