Redact account and customer data before it is shared.
Keep statements, applications, and reports clean without a cloud service.
Where sensitive data leaks out
Financial teams handle account numbers, IBANs, and customer identities that attract both fraud and regulatory scrutiny. Pasting these into AI assistants or converting files online puts sensitive data outside the institution.
Omit apps for financial
PCI DSS tells you how much of a card number may survive
Financial data attracts unusually specific rules, and the specificity is the useful part. PCI DSS version 4 draws a line most teams blur: masking and truncation are different obligations with different permanence. Requirement 3.4.1 governs display, where at most the first six and last four digits of a primary account number may be visible. Requirement 3.5.1 governs storage, where a stored number must be rendered unreadable by strong encryption, truncation, tokenisation or one-way hashing. Masking is temporary and cosmetic. Truncation is permanent and destroys the middle digits for good. Choosing the wrong one is how a compliant-looking export turns out to hold full card numbers underneath.
Display: first six and last four, at most
The BIN and the last four are enough to reconcile a transaction with a customer on the phone. Anything more is over-exposure. The MASK operator preserves exactly the segments you configure, so a statement can be shared for reconciliation without carrying the full number.
Storage: unreadable, by one of four methods
Encryption, truncation, tokenisation or one-way hashing. Omit covers three directly: HASH for one-way, MASK for truncation, and the encrypted vault for reversible tokenisation where the value must stay recoverable under control.
Reversibility is a deliberate choice, not a default
Hashing a card number closes the door permanently. Vault-backed tokenisation keeps it openable by authorised staff. Both are legitimate; the mistake is picking one by accident. Policy is set per entity type so the decision is made once and applied consistently.
The documents this actually applies to
Statements and transaction exports
CREDIT_CARD, IBAN, ACCOUNT_NUMBER, SORT_CODE, PERSON
Routinely exported to spreadsheets for reconciliation, at which point they leave the controls of the core banking system. Omit handles CSV and Excel at the cell level, so account columns can be masked while amounts and dates stay intact and the analysis still works.
Know your customer and onboarding files
PERSON, DATE_OF_BIRTH, national ID numbers, ADDRESS, scanned identity documents
Dense with identifiers by design, since proving identity is the purpose. Most of the content is scanned images, which is where OCR matters: an identity document redacted only in the text layer is not redacted at all.
Loan, mortgage and credit files
PERSON, ACCOUNT_NUMBER, IBAN, employer and salary details
These files travel between broker, lender and underwriter, and every hop is an opportunity to over-share. Redacting to the minimum the recipient needs is easier than negotiating what each party may retain.
Advice notes and client correspondence
PERSON, ACCOUNT_NUMBER, holdings and positions
Identifiers sit in running prose rather than fields, and advisers paste extracts into general purpose AI tools to draft summaries. Protect redacts on paste, so the model receives the substance without the account.
Masking a statement line to the PCI display rule
Before
Payment from Helena Vasquez, card 4539 8812 7734 9061, IBAN GB29 NWBK 6016 1331 9268 19, settled 14 June 2026 for 2,480.00.
After
Payment from [PERSON_1], card 453988XXXXXX9061, IBAN [IBAN_1], settled 14 June 2026 for 2,480.00.
The BIN and last four survive on the card, which is what the display rule permits and what a reconciliation actually needs. The amount and settlement date are untouched, because neither is an identifier and removing them would make the record useless. The IBAN is tokenised rather than masked, because unlike a card number there is no partial form of an IBAN that is both useful and safe.
Showing which method was applied to which field
A PCI assessment turns on whether the right treatment was applied in the right place, not on whether something was redacted. The per-run report records each detection, its type and the operator used, so an assessor can see that stored numbers were hashed or truncated while displayed numbers were masked. Because the report is written during the run, it is contemporaneous evidence rather than a reviewer's later recollection of intent.
What records teams ask first
Further reading
- How to Redact PII From CSV, Excel, and JSON
Omit redacts PII inside structured data files, not just documents: CSV and Excel rewrite the cell, JSON rewrites the value in place, and in every case the file's shape survives. Here is exactly what changes and what does not, format by format.
- What Is PII? Definition, Examples, PII vs PHI
PII means information that identifies a person, but four different laws draw that line in four different places, and the same email address can be in scope under one and arguable under another. Here is each definition, what counts as an example of each, and where PII ends and PHI begins.
- Redaction vs Anonymization vs Pseudonymization
Four words that get used interchangeably and mean four different things, with four different legal consequences. Here is what each one actually does to your data, which regulation defines it, and which one your tool is really performing.
- How to Unredact a PDF, and How to Prevent It
Most recovered redactions come back the same trivial way, because a black rectangle is a drawing and the text is still underneath it. Here is why it happens, how to tell which kind you are holding, and what actually removes a value.
On-device processing keeps customer financial data inside the institution, supporting GDPR and internal data-handling controls, with fail-closed behavior when anything is uncertain.