Real-time screening

Screens an identifier against the Smart Registry and layers the bank's own behavioural signals on top. Covers DPIP use cases 2 to 6 — onboarding, profile change, beneficiary addition, transaction initiation and inward credit.

Screening requestPOST /check · sync

Use case

Identifier type

Value (raw — never leaves the bank)

Transaction & behavioural context — bank-side

Amount (₹)

Channel

Beneficiary added <24h before transfer+11Registered mobile changed <48h before transfer+14Fan-out — 5+ new beneficiaries in 24h+13Amount >6x customer's 90-day average+10Inward credits then immediate full withdrawal+16Device or IP shared with a reported entity+9Structuring below reporting threshold+12

Hash & signing pipeline§7 authentication

Raw—

+ Salt—

SHA-256—

JWS payload—

mTLS → DPIP—

Raw identifiers never leave the bank. The common validation service salts and SHA-256 hashes every identifier, signs the payload with JWS, and the channel is mutual TLS. The central Smart Registry sees only hashes — it cannot reverse them.

No screening run yet. Pick a quick-fill identifier, tick the behavioural context that applies, and screen.

A match is an input, not a verdict. The decision band drives the channel action; a customer-facing consequence still needs the case trail behind it.