> For the complete documentation index, see [llms.txt](https://docs.idlayr.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.idlayr.com/help-center/readme/compliance-and-security.md). # Compliance & Security This page summarises how IDlayr handles data, the security controls applied across the platform, and where to find the current attestations. For the live, audited evidence of each control, refer to the IDlayr Trust Center linked below — that's the canonical source. ## Trust Center The current certifications, policies, sub-processors, and audit reports are published in the IDlayr Trust Center: Treat the Trust Center as the source of truth for what's currently in effect. This page describes the platform's posture in general terms — the Trust Center publishes the specifics. ## Data handling ### What we process To deliver a verification, IDlayr processes the **phone number being verified** and the metadata exchanged with the mobile network operator (MNO) — for example, the device's network-attached number for Secure SNA, the SIM-change status for SIM Swap, the carrier identity for Eligibility. We do not process the user's payment data, identity documents, or other personally identifiable information beyond the phone number and the verification metadata needed to complete the check. ### Data residency The IDlayr platform is deployed across two independent data-residency regions: * **EU** — `eu.api.idlayr.com` * **US** — `us.api.idlayr.com` Customer data submitted to one region stays in that region. Verification activity is processed and stored in the region the API call was made against. Choose the region that matches your data-residency requirement and your customer base. See [Data residency](https://docs.idlayr.com/get-started/concepts/data-residency). ### Retention Verification check records are retained for a defined period that aligns with operational and audit needs. The current retention schedule is published in the Trust Center. ## Security controls ### Encryption in transit All API traffic uses HTTPS with modern TLS. Public, plaintext endpoints are not exposed. Inside the platform, internal service-to-service communication is also TLS-protected. ### Authentication API access is mediated by **OAuth2 client credentials**. Each IDlayr project has a `client_id` and `client_secret`; your backend exchanges them for short-lived access tokens (typically one hour) that are presented as bearer tokens on each API call. See [Authentication](https://docs.idlayr.com/get-started/authentication). ### Callback signing Callback payloads delivered to customer-supplied URLs are **cryptographically signed** (RSA-SHA256 via HTTP Signatures). IDlayr publishes its signing keys via a JSON Web Key Set (JWKS). Redirect URLs followed by the SDK during a Secure SNA or Discovery flow are also signed, with the signature carried in URL query parameters rather than headers. Your callback receiver and redirect handler should fetch the JWKS, verify the signature on every request, and only act on payloads with a valid signature. See [Signed HTTP messages](https://docs.idlayr.com/get-started/signed-http-messages) for the full protocol — payload reconstruction, verification steps, key rotation behaviour, and common pitfalls. ### Access control in the Enterprise Portal The Enterprise Portal supports: * **Single Sign-On (SSO)** — login via your organisation's identity provider. * **Role-Based Access Control (RBAC)** — users only access the projects, environments, and operations relevant to their role. This applies to human access to project configuration, credentials, and verification logs. API access remains gated by OAuth2 client credentials. ### Network access Each project explicitly declares which mobile networks it is enabled against. This is enforced at the platform layer — see the [Updated Network Access Management](https://docs.idlayr.com/changelog#updated-network-access-management) changelog entry and [Allowed Networks](https://docs.idlayr.com/get-started/concepts/allowed-networks). The effect is that an integration can only reach networks that have been provisioned for the project and approved by the carrier. ### Mobile SDK distribution The iOS and Android SDKs are distributed as **private binaries** via Cloudsmith. Fetching them requires a per-customer Cloudsmith entitlement token, separate from the OAuth2 access token. This keeps the SDK out of public package registries and ensures customer integrations can be traced back to a known account at the binary level. See [SDKs](https://docs.idlayr.com/get-started/sdks). ## Compliance posture IDlayr maintains compliance commitments appropriate to a B2B platform serving regulated customers (banks, payment providers, identity vendors). The current set of certifications and audit reports — including any SOC 2 attestations and the scope of each — is published in the Trust Center. If a specific control or attestation is material to your procurement process, request it via your IDlayr account team — see [Support](/help-center/readme/support.md). ## Reporting a security issue Security issues should be reported via your IDlayr account team. They will route the report to the security team and coordinate disclosure. Do not disclose suspected vulnerabilities publicly before coordinating with us. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.idlayr.com/help-center/readme/compliance-and-security.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.