Detections that matter here
Checksums change the rollout.
Most DLP programmes stall at the warn stage, because precision is never good enough to justify blocking. Financial services has an unusual advantage: card numbers and IBANs carry checksums, so false positives are rare enough to block from the outset.
Start enforcement there. A control that is never wrong on its first rule earns the credibility you will need for the context-dependent detectors later.
| Data | Detection | Why it is reliable |
|---|---|---|
| Card number (PAN) | Luhn checksum plus BIN range | Precision target ≥ 0.99 — a good first blocking rule |
| Sensitive authentication data | CVV, PIN block, track data | Never storable post-authorisation; blocks unconditionally |
| IBAN and routing numbers | Checksum-validated | Precision target ≥ 0.98 |
| SSN and TIN | Allocation rules plus context | Context-weighted to control false positives |
| MNPI | Custom rules | Deal codenames, project names, classification headers |
MNPI is the one with no pattern. It is handled through organisation-maintained keyword and regex lists, which means the control is only as current as the list — and a quarterly review with the deal desk is part of operating it rather than an optional extra.
Fitting the stack
Your SOC does not work in a new console.
Itzal pushes to Splunk HEC, Microsoft Sentinel, Google SecOps, Elastic, generic webhooks or RFC 5424 syslog with a CEF payload — at-least-once with a stable event ID for deduplication, plus a cursor-paged pull API so a SIEM that was down for six hours can catch up without a replay request.
Only redacted records go out — including to your own SIEM. Your SIEM has a different retention and access model than the event store, and sending raw content there would launder the boundary rather than respect it.
Before you size other controls
What Itzal does not see here.
An attached chargeback spreadsheet is the highest-volume path for card data in most firms, and it is the one surface the browser extension cannot reach.
Not currently inspected
- Attached exports — a chargeback or reconciliation spreadsheet.
- Screenshots of a transaction log or an account screen.
- Coding assistants, where test fixtures carry live-looking card data.
- Mobile devices.
Straight answers
Can we block card numbers without disrupting developers?
Yes — exception-list your known test card numbers. Blocking checksum-validated PANs while allowing documented test fixtures is the standard configuration, and it removes most of the friction.
How does this reach our SOC?
Splunk HEC, Microsoft Sentinel, Google SecOps, Elastic, a generic webhook, or RFC 5424 syslog with a CEF payload — at-least-once with a stable event ID for deduplication.
Can we detect material non-public information?
MNPI has no reliable pattern, so it is handled through custom rules — deal codenames, project names, document classification headers — which your administrators maintain.