Identity
PAN, Aadhaar offline KYC, voter ID, driving licence and passport — plus face match, liveness and OCR for whatever still arrives as an image.
New Income Intelligence — estimate income with zero documents
Score beforeyou trust.
IdentifyScoreSecure
One API layer for identity, income and fraud intelligence. iScoreIt turns every applicant, merchant and payout account into a decision your team can defend — in under a second.
Signals evaluated
PAN & name matchexact
Bank account (penny drop)verified
Mobile vintage6y 2m
Device fingerprint2 accounts
Email digital footprint11 platforms
Mule & AML watchlistclear
Estimated monthly income₹62,400
iScore
0
Low risk
Policy outcome — Approve, no step-up
Built for banks, NBFCs, fintechs and marketplaces
40+
Verification APIs
<500ms
Median response
99.9%
Platform uptime
1 key
UAT and live, one console
Who it's for
Identify. Score. Secure.
The same platform, tuned to your risk.
Underwrite thin-file borrowers without asking for a single document.
Surrogate and bureau signals give you an income estimate, an ability-to-pay view and a fraud read before the applicant ever uploads a payslip.
- Document-less estimated income for salaried and self-employed profiles
- Bank statement analysis with salary, obligation and bounce detection
- First-party fraud checks on device, mobile vintage and email footprint
- Policy changes shipped from the console, not a release cycle
010 ms
Application received
PAN, mobile, consent captured
02190 ms
Identity & bank verified
Name match + reverse penny drop
03340 ms
Income estimated
Surrogate model, no upload
04412 ms
Decision returned
Approve, limit ₹1.87L
Onboard merchants in minutes, and keep mules out of your payout rails.
KYB, beneficial ownership and payout-account screening run in the same call, so a seller goes live the same day without opening a hole in settlement.
- GSTIN, MCA, Udyam and shop licence checks with director linkage
- UPI ID and bank account verification before the first payout
- MuleNet screening against collection accounts seen in the wild
- Ongoing monitoring — accounts re-scored, not just checked once
01clear
Merchant signs up
GSTIN + PAN submitted
02review
Entity graph built
3 directors, 1 linked entity
03clear
Payout account screened
Not seen on collection pages
04active
Live with monitoring on
Re-scored every 24 hours
AML screening and an audit trail your regulator can actually read.
Every check, every model version and every override is stored against the case. Replay any decision from six months ago exactly as it was made.
- Sanctions, PEP and adverse media screening with tunable match thresholds
- Full decision replay — inputs, policy version, outcome
- Maker–checker on policy changes, with diff history
- Data residency in India, consent artefacts stored with every call
01logged
Case opened
Ref DEC-88214 · 14 Mar
021 hit
Screening run
Sanctions, PEP, adverse media
03closed
Analyst disposition
False positive, note attached
04frozen
Replay available
Policy v14 · model v3.2
API catalogue
Every check you need.
One contract, one console.
Business & KYB
GSTIN, CIN and MCA filings, Udyam, shop & establishment licences, director networks and beneficial ownership — resolved into one entity graph.
Banking & payments
Penny drop, reverse penny drop over UPI, UPI ID validation, IFSC resolution and bank statement analysis with salary and obligation tagging.
Signal intelligence
Device fingerprinting, email existence and digital footprint, mobile vintage and porting history, IP and geo risk — the quiet signals fraud can't fake cheaply.
Income intelligence
A monthly income estimate built from surrogate and bureau signals. No payslip, no statement upload, no drop-off in the middle of your journey.
Fraud & mule intelligence
MuleNet continuously discovers illegal betting and gambling deposit pages, captures the collection UPI IDs, account numbers and QR codes shown on them, and screens your accounts against that evidence repository.
AML & screening
Sanctions, PEP and adverse media screening with tunable thresholds, ongoing rescreening, and dispositions stored against the case for audit.
swipe to explore
Developers
One endpoint.
Every signal.
Send an applicant, name a policy, get a scored decision back with every underlying signal attached. No orchestration code, no vendor-by-vendor error handling, no reconciliation job.
- Idempotent requests and signed webhooks
- Sandbox that returns the same shape as live, with seeded test identities
- SDKs for Node, Python, Java and PHP
- Every response carries the policy and model version that produced it
REQUEST
1# Score an applicant in a single call
2curl -X POST https://api.iscoreit.com/v1/decision \
3 -H "Authorization: Bearer $ISCOREIT_KEY" \
4 -H "X-Environment: live" \
5 -H "Content-Type: application/json" \
6 -d '{
7 "reference_id": "APP-88214",
8 "policy": "retail-pl-v14",
9 "applicant": {
10 "pan": "ABCDE1234F",
11 "mobile": "+919876543210",
12 "email": "asha@example.com"
13 },
14 "checks": ["identity", "bank", "income", "mule", "aml"]
15 }'
16
1import { iScoreIt } from "@iscoreit/node";
2
3const client = new iScoreIt({ apiKey: process.env.ISCOREIT_KEY, env: "live" });
4
5const decision = await client.decisions.create({
6 referenceId: "APP-88214",
7 policy: "retail-pl-v14",
8 applicant: {
9 pan: "ABCDE1234F",
10 mobile: "+919876543210",
11 email: "asha@example.com"
12 },
13 checks: ["identity", "bank", "income", "mule", "aml"]
14});
15
16if (decision.outcome === "approve") {
17 await issueOffer(decision.limit);
18}
19
1from iscoreit import Client
2
3client = Client(api_key=os.environ["ISCOREIT_KEY"], env="live")
4
5decision = client.decisions.create(
6 reference_id="APP-88214",
7 policy="retail-pl-v14",
8 applicant={
9 "pan": "ABCDE1234F",
10 "mobile": "+919876543210",
11 "email": "asha@example.com",
12 },
13 checks=["identity", "bank", "income", "mule", "aml"],
14)
15
16print(decision.score, decision.outcome, decision.limit)
17
1{
2 "reference_id": "APP-88214",
3 "score": 782,
4 "band": "low_risk",
5 "outcome": "approve",
6 "limit": 187000,
7 "policy_version": "retail-pl-v14",
8 "model_version": "3.2.1",
9 "latency_ms": 412,
10 "signals": {
11 "identity": { "pan_name_match": "exact", "aadhaar_offline": "verified" },
12 "bank": { "penny_drop": "verified", "account_holder_match": true },
13 "mobile": { "vintage_months": 74, "recently_ported": false },
14 "device": { "linked_accounts": 2, "emulator": false },
15 "email": { "digital_footprint": 11, "domain_risk": "low" },
16 "income": { "estimate_monthly": 62400, "confidence": 0.87 },
17 "mule": { "match": false, "nearest_hop": 4 },
18 "aml": { "sanctions": "clear", "pep": "clear" }
19 },
20 "reasons": ["thin_file_income_pass", "device_shared_low_severity"]
21}
22
iScoreIt Labs
What we learn from the fraud we see.
Our team publishes what the data shows — how mule chains are actually structured, which signals hold up under pressure, and where verification quietly fails.
Mule networks
Anatomy of a mule chain: how deposit money moves through hundreds of accounts in a single afternoon
Read the studyThin-file credit
Estimating income without documents: which surrogate signals actually predict repayment
Read the studyCustomer
“We were running six vendors and reconciling them by hand. iScoreIt collapsed that into one call and one policy — and the review queue dropped by more than half in the first month.”
This doesn't have to end here
Identify.
Score. Secure.
Bring us your riskiest cohort. We'll run it through the platform and show you what your current stack is missing.
Products
Three products.
One decision surface.
Pulse decides, Verify onboards, MuleNet protects. They share one identity graph, one policy layer and one audit trail — so a signal captured at onboarding is still working for you at payout six months later.
// Decide
The decision engine your risk team can edit themselves.
Rules and models live in one policy layer. Risk writes the policy, engineering keeps shipping features, and every change is versioned the moment it is saved.
Visual policy builder no deploy
Thresholds, waterfalls and step-up logic edited in the console with maker–checker approval.
Shadow & champion–challenger safe rollout
Run a new policy silently against live traffic and compare outcomes before you cut over.
Decision replay audit
Reopen any decision with its exact inputs, policy version and model version intact.
Cost-aware waterfalls spend control
Order your checks so the cheap disqualifying signals run first and the expensive ones only run when they can still change the answer.
retail-pl-v14
1# retail-pl-v14 — edited in the console, versioned on save
2
3when mule.match == true then REJECT
4when aml.sanctions != "clear" then REJECT
5when device.linked_accounts > 4 then STEP_UP
6
7# thin-file path: no bureau history, so lean on surrogates
8when bureau.hit == false
9 and income.estimate_monthly >= 35000
10 and mobile.vintage_months >= 24
11 and email.digital_footprint >= 6
12 then APPROVE
13 limit: income.estimate_monthly * 3
14
15when bureau.score >= 720 then APPROVE
16 limit: bureau.recommended_limit
17
18otherwise then MANUAL_REVIEW
19
1{
2 "reference_id": "APP-88214",
3 "score": 782,
4 "band": "low_risk",
5 "outcome": "approve",
6 "limit": 187000,
7 "policy_version": "retail-pl-v14",
8 "model_version": "3.2.1",
9 "latency_ms": 412,
10 "signals": {
11 "identity": { "pan_name_match": "exact", "aadhaar_offline": "verified" },
12 "bank": { "penny_drop": "verified", "account_holder_match": true },
13 "mobile": { "vintage_months": 74, "recently_ported": false },
14 "device": { "linked_accounts": 2, "emulator": false },
15 "email": { "digital_footprint": 11, "domain_risk": "low" },
16 "income": { "estimate_monthly": 62400, "confidence": 0.87 },
17 "mule": { "match": false, "nearest_hop": 4 },
18 "aml": { "sanctions": "clear", "pep": "clear" }
19 },
20 "reasons": ["thin_file_income_pass", "device_shared_low_severity"]
21}
22
// Onboard
Onboarding journeys that stop asking once they are sure.
Drop-in hosted flows for individuals and businesses, with friction added only where the risk actually sits — not applied uniformly to everyone who walks in.
Hosted or headless your call
Use our journey with your branding, or call the same checks directly from your own app.
Risk-based step-up less drop-off
Selfie and liveness are requested when the signals demand it, not from everybody by default.
UAT and live in one console one key set
Switch environments from a toggle. Same payloads, same webhooks, seeded sandbox identities.
Re-KYC and periodic review stays current
Schedule re-verification by risk band so your book doesn't quietly go stale.
REQUEST
1{
2 "flow": "individual_kyc",
3 "env": "uat",
4 "steps": ["pan", "aadhaar_offline", "bank_reverse_penny_drop"],
5 "step_up": {
6 "trigger": "risk_score < 600",
7 "add": ["selfie_liveness", "address_proof"]
8 },
9 "branding": { "logo_url": "https://you.com/logo.svg", "accent": "#00C8FF" },
10 "redirect_url": "https://app.you.com/kyc/complete",
11 "webhook_url": "https://api.you.com/hooks/iscoreit",
12 "consent": { "captured": true, "artefact_id": "cns_7f21ab" }
13}
14
1// Verify the signature before you trust the payload
2import { createHmac, timingSafeEqual } from "crypto";
3
4export function handler(req, res) {
5 const signature = req.headers["x-iscoreit-signature"];
6 const expected = createHmac("sha256", process.env.ISCOREIT_WEBHOOK_SECRET)
7 .update(req.rawBody)
8 .digest("hex");
9
10 if (!timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) {
11 return res.status(401).send("bad signature");
12 }
13
14 const event = req.body;
15 if (event.type === "decision.completed") {
16 updateApplication(event.data.reference_id, event.data.outcome);
17 }
18
19 res.status(200).send("ok");
20}
21
// Protect
The money-mule map, built from what fraud actually publishes.
Illegal betting and gambling sites have to show a collection account to get paid. MuleNet finds those pages continuously and turns what is printed on them into a screenable, evidence-backed list.
Continuous discovery always on
Crawlers surface new deposit pages and mirrors as they appear, not once a quarter.
Screenshot-backed evidence defensible
Every UPI ID, account number and QR code is stored with the page and timestamp it came from.
Linkage scoring beyond exact match
Accounts one or two hops from a known collection account get scored too, not just the ones on the list.
Payout-time screening before the money moves
Screen a beneficiary at payout, not just at onboarding, so an account that turns bad is caught.
200 OK · 88 ms
1{
2 "query": { "vpa": "redacted@ybl" },
3 "match": "direct",
4 "risk": "critical",
5 "first_seen": "2026-05-02",
6 "last_seen": "2026-07-28",
7 "sources_observed": 7,
8 "category": "betting_deposit_page",
9 "evidence": [
10 { "id": "scr_9f21", "captured_at": "2026-07-28T04:11:00Z" },
11 { "id": "scr_a034", "captured_at": "2026-06-14T19:52:00Z" }
12 ],
13 "linked_accounts": 14,
14 "hops_to_known_mule": 0,
15 "recommendation": "block_and_report"
16}
17
This doesn't have to end here
One platform.
Every decision.
Tell us which decision hurts most right now and we'll show you the shortest path to fixing it.
API catalogue
Forty checks.
One contract.
Every iScoreIt API shares the same authentication, the same error grammar, the same idempotency rules and the same webhook signature scheme. Learn one, and you have learned all of them.
Modules
Grouped by the question they answer.
Identity
PAN, Aadhaar offline KYC, voter ID, driving licence and passport — plus face match, liveness and OCR for whatever still arrives as an image.
Business & KYB
GSTIN, CIN and MCA filings, Udyam, shop & establishment licences, director networks and beneficial ownership — resolved into one entity graph.
Banking & payments
Penny drop, reverse penny drop over UPI, UPI ID validation, IFSC resolution and bank statement analysis with salary and obligation tagging.
Signal intelligence
Device fingerprinting, email existence and digital footprint, mobile vintage and porting history, IP and geo risk — the quiet signals fraud can't fake cheaply.
Income intelligence
A monthly income estimate built from surrogate and bureau signals. No payslip, no statement upload, no drop-off in the middle of your journey.
Fraud & mule intelligence
MuleNet continuously discovers illegal betting and gambling deposit pages, captures the collection UPI IDs, account numbers and QR codes shown on them, and screens your accounts against that evidence repository.
AML & screening
Sanctions, PEP and adverse media screening with tunable thresholds, ongoing rescreening, and dispositions stored against the case for audit.
Endpoint reference
The full catalogue.
Endpoint paths shown for orientation. Full request and response schemas, error codes and rate limits live in the developer documentation.
| API | Endpoint | What it returns |
|---|---|---|
| PAN verification | POST /v1/identity/pan | Validates a PAN and returns name, status and Aadhaar-seeding flag. |
| Aadhaar offline KYC | POST /v1/identity/aadhaar/offline | OTP or XML-based offline KYC with masked storage. |
| Driving licence | POST /v1/identity/dl | Licence validity, holder name, date of issue and vehicle classes. |
| Voter ID / Passport | POST /v1/identity/voter | Electoral roll and passport file-number checks. |
| Face match & liveness | POST /v1/identity/face | Passive liveness plus 1:1 match against the document photo. |
| Document OCR | POST /v1/ocr/extract | Structured extraction with tamper and template checks. |
| GSTIN verification | POST /v1/business/gstin | Registration status, trade name, filing history and address. |
| MCA / CIN lookup | POST /v1/business/cin | Company master data, directors, charges and filing status. |
| Udyam / MSME | POST /v1/business/udyam | Udyam registration details and enterprise classification. |
| Director network | POST /v1/business/network | DIN-based graph of linked entities and shared directors. |
| Penny drop | POST /v1/bank/penny-drop | Credits a token amount and returns the registered account holder name. |
| Reverse penny drop | POST /v1/bank/reverse-penny-drop | UPI-collect based account ownership proof with no debit to you. |
| UPI ID verification | POST /v1/bank/vpa | Validates a VPA and returns the registered payee name. |
| IFSC lookup | GET /v1/bank/ifsc/{code} | Bank, branch, address and supported payment rails. |
| Bank statement analysis | POST /v1/bank/statement | Salary detection, obligations, bounces, and a tamper score. |
| Device intelligence | POST /v1/signals/device | Fingerprint, emulator and root detection, account linkage count. |
| Email intelligence | POST /v1/signals/email | Existence, domain risk, digital age, footprint depth and a recommendation. |
| Mobile intelligence | POST /v1/signals/mobile | Connection vintage, recent porting, SIM swap indicators and operator. |
| IP & geo risk | POST /v1/signals/ip | Proxy, VPN and hosting detection with geo-distance from declared address. |
| Estimated income | POST /v1/income/estimate | Document-less monthly income estimate with confidence and driver weights. |
| Employment check | POST /v1/income/employment | Employer confirmation and tenure from surrogate sources. |
| MuleNet screen | POST /v1/mulenet/screen | Screens a VPA or account against the collection-account evidence repository. |
| MuleNet linkage | POST /v1/mulenet/linkage | Returns hop distance and connected accounts for a beneficiary. |
| AML screening | POST /v1/aml/screen | Sanctions, PEP and adverse media with tunable match thresholds. |
| Ongoing monitoring | POST /v1/aml/monitor | Registers a subject for continuous rescreening with webhook alerts. |
| Decision | POST /v1/decision | Runs a named policy across any combination of the above and returns a scored outcome. |
Sandbox
UAT that behaves
like production.
The sandbox returns the same response shape as live, with seeded identities that deterministically produce clean, borderline and rejected outcomes. Flip one header to go live.
Seeded test identities deterministic
Named fixtures for a clean approve, a device-linked step-up, a mule hit and a sanctions match — so your QA suite can assert on outcomes.
Signed webhooks in UAT same secret flow
Webhook signatures work identically in sandbox, so you test verification once.
Rate limits mirrored no surprises
Sandbox enforces the same per-second ceilings you will hit on the day you launch.
200 OK · 260 ms
1{
2 "reference_id": "INC-40period",
3 "estimate": {
4 "monthly_income": 62400,
5 "range_low": 54000,
6 "range_high": 71000,
7 "confidence": 0.87,
8 "employment_type": "salaried"
9 },
10 "drivers": [
11 { "signal": "bureau_obligation_pattern", "weight": 0.31 },
12 { "signal": "geo_income_index", "weight": 0.22 },
13 { "signal": "mobile_plan_tier", "weight": 0.17 },
14 { "signal": "digital_footprint_depth", "weight": 0.16 },
15 { "signal": "device_class", "weight": 0.14 }
16 ],
17 "documents_required": false
18}
19
1// Verify the signature before you trust the payload
2import { createHmac, timingSafeEqual } from "crypto";
3
4export function handler(req, res) {
5 const signature = req.headers["x-iscoreit-signature"];
6 const expected = createHmac("sha256", process.env.ISCOREIT_WEBHOOK_SECRET)
7 .update(req.rawBody)
8 .digest("hex");
9
10 if (!timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) {
11 return res.status(401).send("bad signature");
12 }
13
14 const event = req.body;
15 if (event.type === "decision.completed") {
16 updateApplication(event.data.reference_id, event.data.outcome);
17 }
18
19 res.status(200).send("ok");
20}
21
1# Score an applicant in a single call
2curl -X POST https://api.iscoreit.com/v1/decision \
3 -H "Authorization: Bearer $ISCOREIT_KEY" \
4 -H "X-Environment: live" \
5 -H "Content-Type: application/json" \
6 -d '{
7 "reference_id": "APP-88214",
8 "policy": "retail-pl-v14",
9 "applicant": {
10 "pan": "ABCDE1234F",
11 "mobile": "+919876543210",
12 "email": "asha@example.com"
13 },
14 "checks": ["identity", "bank", "income", "mule", "aml"]
15 }'
16
This doesn't have to end here
Start in the sandbox.
Ship on Monday.
Sandbox keys are issued the same day. No procurement cycle needed to find out whether this fits.
Solutions
Same platform.
Different question.
A lender is asking “can they repay?” A marketplace is asking “is this the same person as last week?” A payments company is asking “where is this money going?” The signals overlap; the policy does not.
// Lending & NBFCs
Say yes to more thin-file borrowers without loosening your policy.
Most rejections in personal and small-ticket lending are not credit calls — they are missing-data calls. iScoreIt fills the gap with surrogate income, verified banking and a fraud read, so the policy can act on evidence instead of absence.
Personal loans · Two-wheeler · Consumer durables · Business loans · Gold loans
- Document-less income estimation with confidence bands and driver weights
- Reverse penny drop so the disbursal account is proven before money moves
- Bank statement analysis for salary credits, obligations and bounce history
- First-party fraud detection across device, mobile vintage and email footprint
- Policy edits in the console with shadow mode before cutover
// Fintech & payments
Onboard fast, settle safely, and keep collection accounts off your rails.
A payment business lives and dies on who it lets in. KYB, ownership resolution and payout-account screening run together, and MuleNet keeps checking after the merchant is live.
PA/PG · Neobanks · Wallets · Lending-as-a-service · Payout platforms
- GSTIN, MCA and Udyam checks with director and entity linkage
- UPI ID and bank account verification before the first settlement
- MuleNet screening at payout time, not just at onboarding
- Ongoing monitoring with webhook alerts when a beneficiary turns risky
- Full audit trail for every merchant decision you have to defend
// Marketplaces & gaming
Verify sellers and players at signup speed, not review-queue speed.
High-volume consumer platforms need verification that clears the honest majority in seconds and concentrates human review on the small slice that actually warrants it.
E-commerce · Real-money gaming · Gig platforms · Rental · Classifieds
- Risk-based step-up so most users never see a document upload
- Device and account-linkage signals that catch multi-accounting early
- Age and identity assurance where the regulation requires it
- Payout account screening against known collection accounts
- Bulk and asynchronous modes for back-book cleanup
// Insurance
Cleaner proposals in, fewer fabricated claims out.
Verification at proposal stage is cheaper than investigation at claim stage. The same identity and banking checks that clean up onboarding also give the claims team a baseline to compare against.
Life · Health · Motor · Micro-insurance · Distribution platforms
- Proposer identity and bank account verification at issuance
- Income estimation for suitability and sum-assured sanity checks
- Beneficiary account verification before claim settlement
- Device and contact-detail linkage across policies to surface rings
- AML screening for high-value and single-premium products
// Telecom & enterprise
Verify at the point of activation, at the volume you actually operate at.
Distribution networks, retailer onboarding and subscriber activation all need the same primitives — just with throughput and audit requirements that most verification stacks were not built for.
Telecom · Utilities · Logistics · BPO · Large enterprise procurement
- Bulk verification with asynchronous callbacks and status polling
- Retailer and channel-partner KYB with periodic re-verification
- Role-scoped API keys per business unit with separate audit trails
- Cost-aware waterfalls so high-volume flows do not run expensive checks first
- Data residency and retention policies configurable per use case
This doesn't have to end here
Your question,
scored.
Send us the decision you are trying to make. We'll map it to signals and show you the policy that gets there.
Trust & security
Built to survive an audit,
not just a demo.
Verification platforms get asked hard questions by security teams, compliance teams and regulators — usually all three, usually at once. Here are the answers, written down.
Controls
What we hold ourselves to.
ISO 27001
Information security management across the platform.
SOC 2 Type II
Controls tested over a period, not a point-in-time snapshot.
DPDP-aligned
Consent captured, stored and retrievable per data principal request.
Data residency in India
Processing and storage stay inside the country.
Encryption everywhere
TLS 1.3 in transit, AES-256 at rest, keys rotated on schedule.
Role-based access
Scoped keys, IP allowlists and full admin audit logs.
Least-data retention
Configurable retention windows with hard deletion, per endpoint.
Segregated environments
Sandbox and live are fully separate — no shared stores or keys.
Certification statuses shown here are placeholders in this build. Replace each one with your actual certificate, scope and audit date before publishing — and remove any you have not yet been awarded.
Reliability
Degrade gracefully,
never silently.
A verification API that fails closed can stop your business. One that fails open can cost you a lot more. iScoreIt does neither by default — it tells your policy exactly which signal is missing and lets you decide.
- Per-signal status codes rather than an all-or-nothing response
- Automatic failover across upstream sources where more than one exists
- Configurable timeouts per check, so a slow source cannot hold your journey
- Idempotency keys so a retry never double-charges or double-decides
- Public status page and webhook-based incident notifications
Questions we get asked
The security review, answered in advance.
All processing and storage for Indian customers happens inside India. Retention windows are configurable per endpoint, and you can request hard deletion of any record through the console or the API.
No. Data submitted through the APIs is used to answer that request and to serve your own audit trail. It is not pooled into shared training sets. Aggregate fraud intelligence such as MuleNet is built from publicly published collection pages, not from customer submissions.
Every call that touches a personal identifier expects a consent artefact reference. That reference is stored against the decision so you can produce it later — for a regulator, an auditor, or the data principal themselves.
Responses carry a structured status per signal rather than failing the whole call. Your policy decides whether a missing signal means step-up, manual review, or proceed — so an upstream outage does not silently change your approval rate.
Yes. For DigiLocker-based flows we operate as the technology and orchestration layer while you hold your own requester registration, which keeps the regulatory relationship where it belongs.
Decision records, policy versions and model versions are retained for the period you configure, with a default that comfortably covers standard audit cycles. Personal identifiers inside those records can be masked independently of the decision metadata.
This doesn't have to end here
Send us your
security questionnaire.
We would rather answer it up front than three weeks into a procurement cycle.
iScoreIt Labs
What we learn
from the fraud we see.
We publish what the data shows — how mule chains are actually structured, which signals hold up under pressure, and where verification quietly fails. No vendor gloss.
Mule networks
Anatomy of a mule chain: how deposit money moves through hundreds of accounts in a single afternoon
We followed the collection accounts published on a cluster of betting sites for six weeks. The structure is more consistent — and more findable — than most fraud teams assume.
Read the studyThin-file credit
Estimating income without documents: which surrogate signals actually predict repayment
Not every surrogate earns its place in a model. We ranked the ones that survive contact with an out-of-time sample, and the ones that quietly stop working after a quarter.
Read the studyDevice intelligence
The shared-device problem: when account linkage is fraud and when it is a family
Linkage counts are one of the highest-signal, most-misused features in onboarding. A short guide to setting the threshold without rejecting half of a joint-family customer base.
Read the studyOnboarding
Step-up done right: cutting drop-off without lowering assurance
Uniform friction is the most expensive default in KYC. What changes when you request documents from twelve percent of applicants instead of everyone.
Read the studyPayments
Reverse penny drop, explained: what it proves, what it does not, and where it belongs
A practical comparison of penny drop and reverse penny drop across cost, assurance, customer experience and the failure modes each one hides.
Read the studyCompliance
Decision replay: what a regulator actually wants to see six months later
Storing the outcome is easy. Storing the reasoning — inputs, policy version, model version, overrides — is what turns an audit from a fire drill into a query.
Read the studyThese are placeholder titles and summaries for the build. Replace them with your published research before launch — thin or fabricated article pages will hurt your search rankings rather than help them.
This doesn't have to end here
Want the raw
numbers?
We share underlying methodology and sample data with teams evaluating the platform.
About
Identify. Score. Secure.
iScoreIt is a risk intelligence platform for the teams who have to say yes or no to a stranger in under a second — and then explain that answer months later.
Why we exist
Verification answers a field.
Risk teams need an answer.
The gap between “this PAN is valid” and “approve this applicant for ₹1.87 lakh” is where most of the cost, most of the fraud and almost all of the manual work sits. iScoreIt is built to close it.
We come out of lending, not out of a generic API business — which is why the platform is opinionated about things like cost-aware waterfalls, decision replay and what happens when an upstream source goes down mid-journey.
The problem
Six vendors, one decision
Risk teams were stitching together a PAN provider, a bank verification provider, a bureau, a device SDK and two spreadsheets — then reconciling the answers by hand. The decision was never the hard part. Getting trustworthy inputs to it was.
The idea
Score, don't just verify
A verification API tells you a field matched. That is not a decision. We wanted a layer that collects the signals, weighs them against a policy you control, and returns something you can act on and later defend.
The build
One contract across every check
Same auth, same error grammar, same idempotency, same webhook signature — across identity, banking, business, device, income and AML. Learn one endpoint and you have learned all of them.
The differentiator
Fraud intelligence from the open web
MuleNet came out of a simple observation: illegal collection operations have to publish an account to get paid. That published evidence, gathered continuously, is a fraud dataset nobody else was assembling systematically.
How we build
Four things we will not trade away.
Evidence over assertion
Every score comes with the signals that produced it. If we cannot show you why, we do not ship it.
Fail loud, not open
A missing signal is reported as missing. Your policy decides what that means — we never quietly substitute a default.
The customer holds the relationship
Where a regulated registration belongs to you, it stays with you. We are the technology layer, not a middleman on your compliance.
Boring where it matters
Auth, idempotency, versioning and audit trails are unglamorous and non-negotiable. The interesting work sits on top of them.
40+
Verification APIs
<500ms
Median response
99.9%
Platform uptime
1 key
UAT and live, one console
This doesn't have to end here
Come break it
on your data.
The fastest way to evaluate us is a sandbox key and your own back-book sample.
Contact
Tell us the decision
you are trying to make.
Book a demo, request sandbox keys, or send a security questionnaire. Whichever it is, you will get a person who has worked in risk — not a form response.
Direct
Or just email us.
Reaching out directly is usually faster than a form, and it lands with the same people.
Sales & demos
Developer support
Security & compliance
Before you ask
The four questions everyone opens with.
Same day in most cases. Sandbox keys do not require a signed contract — we would rather you test against real response shapes before anyone talks about commercials.
Yes. The most useful evaluation is a back-book sample scored against your current outcomes, so you can see where the platform would have decided differently and why.
Usage-based per check, with volume tiers and a platform component for the decision engine. Pricing is quoted against your actual mix of checks rather than a single blended rate.
Most customers do. A single high-value check — reverse penny drop, income estimation or MuleNet screening — is a common first integration, with the decision engine added later.
This doesn't have to end here
Identify.
Score. Secure.
Sandbox keys the same day. No procurement cycle needed to find out whether this fits.