Redact Aadhaar numbers, PAN, phone numbers, and signatures — both on the document image and in the JSON response. Fully reversible with key-controlled unmasking and audit-logged access.
Different systems have different needs. Your customer support team doesn't need the Aadhaar number; your auditor might. Our API respects that.
Detects PII regions on scanned document images and blacks out the pixels. Returns a new image with bounding-box masks — safe to share downstream.
Mask specific JSON fields in API responses. Choose which fields to mask per role or per endpoint — pass a mask_fields array.
"aadhaar": "XXXX XXXX 9012", "pan": "ABXXX1234F", "mobile": "+91 98765 43210"
For data shared with untrusted systems or third-party analytics: mask PII irreversibly. The original values are never stored — your compliance obligation ends at the API call.
mode: "irreversible" → keys destroyed → no unmask possible
Masked values are encrypted in a per-customer vault with your KMS key. Authorized roles can unmask on demand — every access logged, every reason recorded.
mode: "reversible" vault: "kms_8B3A2F" unmask: role+reason
Trained specifically on Indian identifier formats. We don't just detect patterns — we understand context.
Data minimisation isn't optional anymore — regulators have moved from "best practice" to "findable in audit observations". Recspace masking was designed to the letter of the obligation.
Aadhaar numbers in displays and downstream systems are masked to the last 4 digits by default — aligned with UIDAI guidance and RBI circulars.
Data minimisation, purpose limitation, and consent tracking built in. Every PII access is logged against a stated purpose and retention window.
Reversible masking uses per-customer AWS KMS keys. You control rotation, you control access — we never see the plaintext after masking.
# Mask specific fields in a KYC response curl -X POST https://api.recspace.in/v1/masking/apply \ -H "Authorization: Bearer $API_KEY" \ -H "Content-Type: application/json" \ -d '{ "payload": { ... KYC output ... }, "mask_fields": ["aadhaar", "mobile", "address"], "mask_mode": "reversible", "purpose": "customer_support_view", "retention_days": 90 }' # → 200 OK · 180ms { "mask_id": "mask_8B3A2F", "masked_payload": { "name": "Priya Sharma", "aadhaar": "XXXX XXXX 9012", "mobile": "+91 XXXXX 43210", "address": "XXX, XXX, Delhi" }, "vault": { "kms_key": "arn:aws:kms:ap-south-1:...", "expires_at": "2026-07-19T00:00:00Z" }, "reversible": true }
Regulators don't just want to know the data is masked. They want to know who has seen the raw value, when, and why. That ledger is built in.
Every unmask API call is written to a tamper-evident append-only log, with the operator's identity (from your SSO), timestamp, access purpose, and the specific field accessed.
Ship it to your SIEM via webhook, pull it into your audit platform via REST, or download the full session trace for a regulator visit.
View audit log format →We'll help you map which fields to mask, where, and for whom — aligned with your specific compliance posture.