> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Singapore PDPA (PDPC SG + DNC Register) > Run Singapore outbound on the PDPA's deemed-consent line: record the basis per contact and channel, pre-flight every +65 send through the DNC scrub chain, file DSARs on the 30-day pdpa clock, and hold the accountability records the PDPC SG asks for. # Singapore PDPA (PDPC SG + DNC Register) Singapore's Personal Data Protection Act (2012, amended 2020) is an opt-out-flavoured regime: consent may rest on deemed consent, including the deemed-by-business-necessity class the 2020 amendment codifies, and the access-and-correction right runs on a 30-day clock. What separates Singapore from every other APAC market is Part 9, the Do Not Call provisions: marketing calls, SMS, and faxes to +65 numbers must scrub against the national DNC register unless the recipient's consent is captured in the form Part 9 accepts. The regulator is the Personal Data Protection Commission (PDPC SG), and the duty sits on the organisation sending, not on the platform it sends through. Which basis fits your processing, and whether the DNC register reaches a given campaign, is a judgement for your counsel; Orbit ships the controls that record the answer you reach. The combined [Singapore and Thailand PDPA Posture](/compliance/pdpa-singapore-thailand) page holds the cross-market obligation map; this page is the Singapore-only checklist and worked sequence. Thailand's self-standing page is [Thailand PDPA](/compliance/thailand-pdpa). This page describes Orbit's platform controls. It is **not legal advice.** Which PDPA obligations apply to you — deemed consent or express, whether the DNC register reaches your traffic, what basis fits a cross-border transfer — depends on your processing. Confirm with qualified counsel. *** ## The SG checklist **Data-residency posture.** Singapore imposes no bright-line localization on most private-sector processing; the 2020 amendment requires a comparable standard of protection on transfers out of Singapore, which is an assessment you run on your transfer basis. For voice, the residency pin ([Voice Data Residency](/compliance/voice-data-residency)) records where recordings physically live, and BYOK ([BYOK Customer Managed Keys](/compliance/byok-customer-managed-keys)) carries the localization claim where a buyer or reviewer needs it. Map the whole transfer posture per [Data Residency Overview](/compliance/data-residency-overview). **Sender registration.** The `SG` rows returned by `GET /compliance/country-rules?channel=sms` typically read `recommended` for alphanumeric sender IDs, the lightest registration level among the long-tail markets. File the registration through your operator or aggregator and wire its status into your compliance profile before production traffic; the row, not this page, is authoritative, and [Country Compliance Requirements](/compliance/country-requirements) documents the read. Sender-format rules live on [Singapore SGNIC Sender Rules](/compliance/singapore-sgnic-sender-rules). **KYC document roles.** Carrier-facing or aggregator-facing filings attach to the [KYC identity model](/compliance/kyc-identity-model): corporate identity as `business_doc`, address evidence as `address_proof`, individual signers as `id_proof`. Orbit never files a registration on your behalf; it exposes the row and the gate and delivers once the row reports `approved`. **Opt-in aliases.** Singapore marketing follows the deemed-consent line: you may send on a disclosed, recorded basis until the recipient opts out, subject to the DNC register. English `STOP` aliases are the canonical APAC expectation and each reply writes a suppression entry; extend the vocabulary on the [Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table) where your traffic needs more. Store the consent record with `lawful_basis` and a `purpose` string per `(contact, channel)` pair so the deemed-consent nuance the 2020 amendment codifies is recorded, not assumed. **DSAR clock.** Access-and-correction requests from Singapore data subjects file under `applicable_jurisdiction: "pdpa"` — the **30-day clock** the [DSAR page](/compliance/dsar) applies automatically under that code. Erasure outcomes flow into suppression so a deleted +65 contact cannot silently re-enter marketing sends. **DST concern.** Singapore sits at a fixed UTC+8 with no DST. No statutory quiet-hours window exists; the restraint inherits from carrier practice. Set a recipient-timezone-resolved default (21:00–08:00 SG time) on [Quiet-Hours Configuration](/guides/quiet-hours-configuration) and validate it with [Quiet-Hours Preview](/compliance/quiet-hours-preview). The safety property is timezone fixity, not the window itself. *** ## Worked sequence for a Singapore recipient **Step 1 — capture consent with the basis.** ```bash theme={null} curl -X POST https://api.orbit.devotel.io/api/v1/compliance/consent \ -H "Authorization: Bearer $ORBIT_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "identifier": "+6591234567", "channels": ["sms"], "opt_in": true, "consent_type": "marketing", "lawful_basis": "consent", "purpose": "Marketing SMS — purpose disclosed at signup (SG PDPA s13 duty)." }' ``` **Step 2 — DNC scrub before outbound.** Pre-flight the list through `GET /compliance/dnc/check` and read the `source` and `last_synced_at` fields; treat a stale row as a risk flag, not a blocker, per the fail-open caveat on [DNC Scrubbing](/compliance/dnc-scrub). The feed that refreshes the SG country row carries the register link — see [Country Rules Auto-Refresh Feeds](/compliance/country-rule-feeds). **Step 3 — wire withdrawal to suppression.** `STOP` replies, the consent API with `opt_in: false`, and the preference center all land on one suppression list; a revoked +65 contact stays suppressed regardless of the entry point — [Opt-Out & Suppression Lists](/compliance/opt-out-suppression). **Step 4 — file a DSAR on the `pdpa` clock.** ```bash theme={null} curl -X POST https://api.orbit.devotel.io/api/v1/compliance/dsar \ -H "Authorization: Bearer $ORBIT_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "subject_email": "jordan@example.sg", "requester_email": "privacy@your-company.sg", "applicable_jurisdiction": "pdpa", "request_type": "know", "requester_statement": "PDPA access request (Singapore data subject, s21 duty)." }' ``` **Step 5 — hold the accountability records.** File each SG-facing activity in the [Privacy Register](/compliance/privacy-register); record notifications to the PDPC SG in the [Breach Incident Register](/compliance/breach-incident-register) — the notification itself is your act, the attestation records the judgement behind it. When a reviewer asks for the whole program, the [Evidence Binder](/compliance/evidence-binder) assembles it. *** ## Related references * [Singapore and Thailand PDPA Posture](/compliance/pdpa-singapore-thailand) — the cross-market surface map this page splits for Singapore. * [Thailand PDPA](/compliance/thailand-pdpa) — the companion market's express-consent posture. * [Singapore SGNIC Sender Rules](/compliance/singapore-sgnic-sender-rules) — the SG sender-format and registration page. * [DNC Scrubbing](/compliance/dnc-scrub) — sources, freshness, and the check endpoint the SG pre-flight wires. * [Country Rules Auto-Refresh Feeds](/compliance/country-rule-feeds) — what keeps the SG row current. * [Consent Management](/compliance/consent-management) and [Consent Posture: The Unknown-Consent Policies](/compliance/consent-default-policy) — the lawful-basis fields and the two posture knobs. * [DSAR](/compliance/dsar) — the coded jurisdictions, `pdpa` at 30 days, and the proof-of-deletion certificate. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.