> For the complete documentation index, see [llms.txt](https://docs.fraudcheck.co.za/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fraudcheck.co.za/product/products/screening/self-exclusion.md). # Self-exclusion screening Screens players at sign-up against the operator's own gambling self-exclusion list. A gambling and iGaming product for licensees that must refuse excluded persons. It screens a person at sign-up against the gambling self-exclusion list the operator already receives from its licensing authority, which we host in an encrypted architecture inside the operator's own tenant. It returns a match result for the operator to act on, and never blocks the customer automatically. Each operator's list is ring-fenced: it is never shared with, compared against or used by any other client or product. ## How it works The operator uploads the exclusion list it receives from its licensing authority through the client portal, as a CSV file: either a full **baseline** replacement or a **delta** of additions and revocations. Each file is validated and applied in full or rejected in full, and every upload produces a reconciliation report. At sign-up, the operator submits the customer's identifier. We normalise it and match it against that operator's list only. Screening is only as current as the most recent upload, so list freshness is returned with every result. ## What it returns An overall result. On a match, also the exclusion reference, exclusion type, effective dates and source authority. Every result carries list freshness: the source document date and the date of the operator's last upload. ## Inputs required The person's 13-digit South African ID number or passport number, first name and last name, and confirmation of consent. Matching uses the ID or passport number only. The operator must have uploaded an exclusion list before screening can run. ## Data source The operator's own self-exclusion list, received from its licensing authority and uploaded through the portal. ## Consent and permissible purpose You must obtain the person's consent before screening them, and confirm on each request that you have it. You keep the proof of consent; Fraudcheck records that you confirmed it. See [Consent and permissible use](/product/overview/how-it-works/consent.md). We never make the block decision: the statutory duty to refuse an excluded person stays with the licensee. ## Channels Screening requests are available through the API only. For request and response detail, see the [API reference](https://developer.fraudcheck.co.za/consumer-service/aml-and-watchlist/self-exclusion-screening). Operators manage their exclusion list, including uploads, under **Verifications > Exclusion list** in the portal. ## Outcomes * **Accept**: the person is not on the operator's list. * **Reject**: the ID or passport number exactly matches a record on the operator's list. The check only reports the match. The decision to refuse the person stays with the operator. ## Turnaround Real-time. ## When to use it Screening new players at registration, before an account is opened or a first deposit is accepted. It also helps show a regulator that self-exclusion checks run consistently at onboarding against a current list, backed by a full audit trail of uploads, screens and results. --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.fraudcheck.co.za/product/products/screening/self-exclusion.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.