Verifies input data against the official data service in China. Didit exposes this service through `POST /v3/database-validation/` so you can verify the submitted data against the authoritative source and receive normalized match results. ## Coverage * **Coverage:** \~ 100% * **Country:** China * **Service ID:** `chn_bank_card` * **Data domain:** Financial * **Category:** Banking ## Inputs | Field | Required | Example | | ------------------ | -------: | -------------------- | | `full_name` | Yes | `王新伟` | | `date_of_birth` | Yes | `1990-01-01` | | `national_id` | Yes | `11010519900101003X` | | `bank_card_number` | Yes | `4111111111111111` | | `vendor_data` | No | `user-1234` | * **Required inputs:** `full_name`, `date_of_birth`, `national_id`, `bank_card_number` * **Optional inputs:** `vendor_data` * **Consent:** Required * **Workflow availability:** Standalone API only * **Coverage:** \~ 100% * **Price:** \$0.40 per successful query ## Body parameters ISO 3166-1 alpha-3 country code for this database service. Example: `CHN` Array containing this service ID. Pinning the service keeps the request scoped to this exact database. Example: `chn_bank_card` Explicit end-user consent for this service. Example: `true` Full legal name to validate. Example: `王新伟` Date of birth in `YYYY-MM-DD` format. Example: `1990-01-01` National identity number for this service. Example: `11010519900101003X` Bank card number. Example: `4111111111111111` Your stable user reference for this person, such as your internal user ID. Didit uses it to link standalone checks to the same end user and reduce duplicate-detection noise. Example: `user-1234` ## Input rules & validation notes * Chinese resident identity card number (15 digits or 18 characters with checksum) * `national_id` must match `(?:\d{15}|\d{17}[\dXx])`. * The final Chinese Resident Identity Card check character is validated. * `full_name` must be the original Chinese-script name as it appears in the registry or on the document. Do not send the Latin transliteration for China database checks. ## How to call it ```bash cURL theme={null} curl -X POST "https://verification.didit.me/v3/database-validation/" \ -H "x-api-key: YOUR_API_KEY" \ -F "issuing_state=CHN" \ -F "services=chn_bank_card" \ -F "vendor_data=user-1234" \ -F "consent=true" \ -F "full_name=王新伟" \ -F "date_of_birth=1990-01-01" \ -F "national_id=11010519900101003X" \ -F "bank_card_number=4111111111111111" ``` Every successful call returns HTTP `200`. The **`outcome_code`** field tells you what actually happened — distinguishing, for example, a real biometric mismatch (`BIOMETRIC_NO_MATCH`) from a selfie that could not be read (`BIOMETRIC_IMAGE_UNUSABLE`). The `status` shown is the default feature status; your configured [Partial Match / No Match actions](/core-technology/database-validation/database-validation-warnings) can override it. **`MATCH`** — The registry confirmed the identity and every checked field matched. ```json 200 OK — MATCH theme={null} { "request_id": "req_01H…", "status": "Approved", "issuing_state": "CHN", "match_type": "full_match", "validations": [ { "outcome_code": "MATCH", "service_id": "chn_bank_card", "service_name": "China Bank Card", "source_data": { "date_of_birth": "1990-01-01", "full_name": "王新伟", "identification_number": "11010519900101003X" }, "validation": { "date_of_birth": "full_match", "full_name": "full_match", "identification_number": "full_match" } } ] } ``` **`PARTIAL_MATCH`** — The identification number was found but one or more personal fields (usually name or date of birth) did not fully match. ```json 200 OK — PARTIAL_MATCH theme={null} { "request_id": "req_01H…", "status": "In Review", "issuing_state": "CHN", "match_type": "partial_match", "validations": [ { "outcome_code": "PARTIAL_MATCH", "service_id": "chn_bank_card", "service_name": "China Bank Card", "source_data": { "date_of_birth": "1990-01-01", "full_name": "王新伟", "identification_number": "11010519900101003X" }, "validation": { "date_of_birth": "full_match", "full_name": "no_match", "identification_number": "full_match" } } ] } ``` **`NO_MATCH`** — The registry returned no match for the submitted data. ```json 200 OK — NO_MATCH theme={null} { "request_id": "req_01H…", "status": "Declined", "issuing_state": "CHN", "match_type": "no_match", "validations": [ { "outcome_code": "NO_MATCH", "service_id": "chn_bank_card", "service_name": "China Bank Card", "source_data": { "date_of_birth": "NO_MATCH", "full_name": "NO_MATCH", "identification_number": "NO_MATCH" }, "validation": { "date_of_birth": "no_match", "full_name": "no_match", "identification_number": "no_match" } } ] } ``` ## Returned data The exact fields surfaced in `source_data` depend on what the registry returns. The generated example for `chn_bank_card` currently documents this normalized shape: * `date_of_birth` * `full_name` * `identification_number` ## Pricing & SLAs China Bank Card queries are billed only when Didit receives a conclusive result from the validation source. * **Per-call price:** \$0.40 USD. * **Billing:** per successful query. You are not charged when the registry is unreachable, when required fields are missing, or when the request is rejected before reaching the source. * **Latency:** typical p95 \< 2 s. * **Availability:** 99.9% per quarter on Didit's side; downstream source availability varies by country and dataset. ## Continue reading * [China Database Validation overview](/api-reference/database-validation/china) * [Database Validation overview](/core-technology/database-validation/overview) * [Outcome Codes](/core-technology/database-validation/database-validation-outcome-codes)