7 DLP Rules Every Indian Fintech Should Configure on Day 1

Indian fintechs and NBFCs handle data the rest of the economy does not: PAN numbers in bulk, Aadhaar references, bank account numbers, IFSC codes, KYC documents, credit-score data, lending decisions. RBI and (where applicable) IRDAI and SEBI all expect demonstrable controls.

This post gives you the seven highest-impact DLP rules to configure on day 1, with the exact regex patterns. The rules below cover the bulk of the exfiltration paths we have seen across 40+ Indian fintech deployments.

Rule 1: Block bulk PAN-number paste

PAN numbers leak through CSV exports, copy-paste from CRM into external apps, and clipboard scrapes. A single PAN in a document is normal. Five or more PANs in a single paste operation is almost always exfiltration.

Detection pattern:

Regex: \b[A-Z]{5}[0-9]{4}[A-Z]\b
Trigger: 5+ matches in a single clipboard event or file write
Action: Block + alert + audit

Why 5+ as the threshold: single PAN matches generate noise (signing one customer's KYC, looking up one record). Five-or-more catches the bulk case without flooding the SOC.

Rule 2: Block bulk Aadhaar-number paste

Aadhaar is sensitive personal data under the IT Rules 2011 and DPDP Act 2023. Different valid formats need different handling:

Regex (12-digit form): \b[2-9]\d{3}\s?\d{4}\s?\d{4}\b
Verification: Verhoeff checksum (rejects false positives)
Trigger: 3+ matches in a single paste/file write
Action: Block + alert + audit

The Verhoeff-checksum verification step matters — without it, you flag any 12-digit number which produces 100+ false positives per day in a busy fintech.

Rule 3: Flag bank-account exports over threshold

Indian bank account numbers range from 9 to 18 digits depending on bank. The cleanest detection is contextual — account-number patterns appearing next to IFSC codes or in CSV export operations.

Composite pattern:
  IFSC regex: \b[A-Z]{4}0[A-Z0-9]{6}\b
  Account number: 9-18 digit numbers within 50 characters of an IFSC match
Trigger: 10+ composite matches in a file write or upload
Action: Block external upload, flag internal save

Rule 4: Block USB writes for unmanaged files

USB is the #1 fintech exfiltration vector by event count. Block writes of unmanaged file types entirely; allow only document classes that pass through DLP inspection first.

• Always blocked: .db, .mdb, .sql, .bak, .ldf, .mdf, .pst (database and email-store formats)
• Inspected before allow: .xlsx, .csv, .pdf, .docx — content scanned for the patterns above
• Always allowed: .txt under 1 MB, signed PDFs from approved sources

Pair with a USB device whitelist for legitimate use cases (audit teams, IT swaps). Whitelisted devices still inspect content; they just do not block on device class alone.

Rule 5: Flag cloud-upload spikes

Personal Dropbox, Google Drive, OneDrive, and WeTransfer uploads exceeding 50 MB in a single session almost always warrant investigation in a fintech context.

Detection:
  Domains: dropbox.com, drive.google.com, onedrive.live.com,
           wetransfer.com, mega.nz, sendspace.com, send.tresorit.com
  Threshold: 50 MB upload per session, OR 200 MB cumulative per day
Action: Flag (do not block); route to manager review

Why flag rather than block: legitimate use cases exist (sharing a presentation with an external auditor). Investigation queue is fine. Hard block creates support-ticket pain.

Rule 6: Block credit-card-number paste outside payment apps

PCI DSS-aligned but more focused. Credit-card numbers (Luhn-valid) appearing outside the company's payment-processing application are inherently suspicious.

Regex: \b(?:4\d{12}(?:\d{3})?|5[1-5]\d{14}|3[47]\d{13}|6(?:011|5\d{2})\d{12})\b
Verification: Luhn checksum
Allowed apps: [your payment processor SDK], [internal CRM], [Razorpay/Cashfree dashboards]
Action: Block + alert when match occurs in any other app

Note: the allowed-apps list is critical. Without it, your support team gets blocked when they paste a customer's last-4 digits into a chat window. Allow contextually, block elsewhere.

Rule 7: Audit screenshots when banking apps are in focus

Sensitive customer screens (loan-approval views, KYC document pages, transaction history) should not be screenshotted by employees with mobile phones. Detecting phone-photo capture is hard; detecting in-app screenshot is trivial.

Detection: Windows screen-capture API event while
           target app process is in focus.
Target apps: [your loan origination], [KYC service], [core banking client]
Action: Audit log + capture a watermarked copy of the screenshot
        with employee ID + timestamp embedded
Manager review: weekly

The watermark is the key trick: even if a legitimate use case exists (training material), the captured screenshot now has accountability built in. Misuse becomes traceable.

Common false positives and how to tune

The order of deployment

Do not deploy all seven at once with blocking actions. The recommended phased rollout:

1. Week 1: All seven rules in monitor-only mode. Log fires, do not block. Collect baseline volumes.
2. Week 2: Tune thresholds and add allowlists based on week-1 noise.
3. Week 3: Switch rules 1, 2, 3, 4 to block. Keep 5, 6, 7 in alert mode.
4. Week 4 onwards: Tune block-rule thresholds based on legitimate user pushback. Switch rules 5-7 to block once stable.

For the full 30-day playbook including tuning workflow, see our DLP 30-day setup playbook.

FAQ

Do these rules satisfy RBI cyber-security framework requirements?

They are necessary but not sufficient. The framework requires DLP plus several other controls (network segmentation, privileged access management, vulnerability scanning). See our RBI checklist for the complete picture.

What about handling OTPs and one-time passcodes?

Separate rule. Six-digit OTP patterns inside customer-facing chat or email warrant immediate flag. Treat as sensitive personal data under the IT Rules 2011.

How long should DLP alert data be retained?

Three years minimum for fintech (RBI audit window). Configure your monitoring tool's retention policy explicitly — default 30 days is too short.

Should these rules apply to senior management too?

Yes, with judgement. Senior leaders legitimately handle aggregated customer data. Tune their thresholds higher rather than exempt them — historical insider-threat data from Indian fintechs shows senior fraud cases are not rare.