Data-driven decisions
Set credit limits from verified income and fraud signals, and re-check cardholders as their risk changes.
← Use cases / Card issuing
Low-friction signup. High-signal fraud prevention.
Verify identity with document and biometric matching, then screen the device behind the application — so synthetic identities are caught before a physical or virtual card is ever issued.
The shape · Stacked layers — each check adds a layer of trust before a card is issued.
The problem
Card issuers are squeezed from both sides — a slow, document-heavy KYC flow kills signup conversion, but a fast, low-friction flow is exactly what synthetic-identity fraud rings are built to exploit. A card issued to a fabricated identity is a loss the issuer absorbs, often only discovered after the card has already been used.
The solution
Smile verifies identity and screens the device in the same signup flow, so low friction and high fraud signal aren't a tradeoff — a genuine applicant clears in seconds, while a synthetic identity or device already linked to other applications gets flagged before issuance.
What changes
How it works
From trigger to decision, in four steps.
STEP 1
Trigger the event
An applicant submits an ID document and completes a liveness check during card signup on your frontend.
STEP 2
Call the API endpoint
Your backend sends a POST request to /v1/verifications with the applicant's name, date of birth, and government ID number.
STEP 3
Real-time processing & webhooks
Smile matches the document and biometric against source records and checks the originating device for spoofing or reuse, returning the result immediately, or through the VERIFICATION_COMPLETED webhook when processing is asynchronous.
STEP 4
Deliver the output
Your issuing system receives the match result and either provisions the card immediately or routes it to manual review.
The code
Request in, structured data out.
Request — cURL
curl -X POST "https://sandbox.smileapi.io/v1/verifications" \
-u "$SMILE_CLIENT_ID:$SMILE_CLIENT_SECRET" \
-H "Content-Type: application/json" \
-d '{
"firstName": "George",
"middleName": "Cimafranca",
"lastName": "Palomero",
"suffix": "Jr.",
"fullName": "George Cimafranca Palomero Jr.",
"additionalData": {
"dob": "1970-08-24",
"gender": "Male",
"ids": [
{ "idType": "tin_ph", "idSubType": null, "idNumber": "123456789" }
]
},
"consent": {
"type": "Terms And Conditions",
"version": "1.0",
"consentedWith": "I agree to the terms and conditions.",
"consentedAt": "2021-04-14T09:30:24Z",
"consentTemplateId": null
}
}'Response — 200 OK
{
"code": "OK",
"message": "Success",
"requestId": "5b79399a-6852-4234-bb0e-ad472648282d",
"data": {
"id": "5b79399a-6852-4234-bb0e-ad472648282d",
"createdAt": "2021-04-14T09:30:24Z",
"updatedAt": "2021-04-14T09:30:24Z",
"status": "PROCESSING",
"errorMessage": null,
"requestMeta": { … },
"result": null
}
}Security & reliability
Built to be trusted in production.
Data privacy & compliance
Data is encrypted in transit and at rest, sensitive fields are tokenized rather than stored in the clear, and consent is captured at the point of collection — adapted to the data privacy regulations applicable in each market you operate.
Reliability
Idempotent requests, built-in retry support, and published rate limits mean a dropped connection or a retried request never produces a duplicate check. Each client can make up to 20 requests per second per IP address across all endpoints; anything above that returns HTTP 429.
Graceful failure
Every error returns a descriptive status code and a structured JSON body with a machine-readable code and a request ID — never a bare 500 — so a failed check is something your application can handle, not just log.
Under the hood
Relevant products
AI & data-driven decisions
How does Smile API power AI and data-driven decisions?
Smile API gives card issuers one verified applicant profile. Issuing models and AI agents can use it to decide approvals and starting limits, and to watch for risk after the card is live.
Features for your models
Clean, labelled and consented attributes — identity, income, device and watchlist outcomes — ready to use as inputs for credit and fraud scoring models.
Context for AI agents
An onboarding agent can approve the applicant, propose a starting limit and flag accounts for review when monitoring signals change.
How does Smile API help AI in card issuing?
- It provides verified identity, income and fraud signals as structured data, so an issuing model or AI agent can decide approval and limits consistently and re-assess cardholders over time.
Is Smile API data structured for machine use?
- Yes. Results come back as consistent, typed JSON fields — verification statuses, scores and flags — so rules engines, machine learning models and large language model agents can read them without manual cleanup.
How is consent handled when AI uses Smile API data?
- Every request carries the consent record captured from the end user, and Smile returns only the signals that consent covers. Your models and agents work with permissioned data, never scraped or self-reported guesses.
{
"profile": "prf_8f21",
"identity": "verified",
"income": { "status": "verified", "source": "payroll" },
"device": "trusted",
"fraudScore": 0.07,
"watchlists": "cleared",
"suggestedAction": "approve"
}