Document Redaction for Financial Services

The financial sector is undergoing a transformation. Long gone are the days when customer data was siloed in shiny skyscrapers and accessed by only one institution. Now, in the era of open banking and fintech, customers have complete control of their own data – and they can choose to share it with whichever businesses and third parties they like. Or not.

Customers may get the final say on who can access their personal information, but the responsibility for protecting that information still falls to financial institutions. In a recent article, we explored the balancing act between data privacy and product personalization in open banking. To sum it up, customers want the best of both worlds. They want the freedom to share information so they can receive customized services, and an ironclad assurance that their data is being kept secure.

Most open banking best practices come back to preserving privacy, and redaction is the mechanism that does it at the document level. Read on for how secure document redaction works on financial documents, and what it does not do.

In its simplest form, redaction is the process of identifying and removing sensitive information in a document. The idea isn’t to make the document useless, though – it’s about preventing unauthorized access to protected personal data while ensuring the document still conveys important information. Redaction enables documents with sensitive info to be safely distributed to a wider audience for a specific purpose.

Before the computer age, redaction was done manually with paint, tape, or black markers. Despite the advances in redaction technology, it can be tempting to quickly pass a Sharpie over a document out of convenience. However, we don’t recommend this method. Sony recently experienced a breach of confidential financial data due to documents that had been redacted with a marker. Long story short, Sharpies and scanners don’t mix.

The finance sector handles all kinds of documents with personal info, including financial statements, mortgage and loan applications, transaction records, and securities forms. Secure and permanent redaction is a foundational method for protecting confidential customer data and remaining compliant with regulations like GDPR (the General Data Protection Regulation).

Removing is the operative word. Drawing a black rectangle over an account number leaves the digits in the content stream underneath, where they can be selected, copied or extracted. True redaction destroys the text, image and vector content inside the marked region, and the operation is irreversible once applied. See true redaction versus visual masking.

Learn more about PDF redaction in our Ultimate Redaction Guide.

The first step in enhancing customer trust is to, well, avoid doing anything illegal or non-compliant. Although with 137 countries having some form of data protection legislation in place and new fintech solutions coming to the marketplace at speeds that tend to move faster than legislation, this is actually more of a challenge than it might seem.

No matter where you are in the world, ensuring financial document compliance is key to credibility and trust. To ensure documents stay compliant, it’s also essential to have redaction technology that’s flexible enough to keep up with the evolving regulatory landscape. The Apryse WebViewer SDK provides regex-based (regular expression-based) redaction. This enables you to automatically identify and mark personal information like credit card numbers, addresses, names, and more for redaction, so documents reach review already prepared.

If the compliance rules change, all you have to do is define an additional custom pattern for the specific content you need to redact. This helps protect customer data quickly and effectively.

For more in-depth technical details about regex-based redaction, check out our developer documentation.

Redaction is inextricably linked to data privacy. Protecting financial data is the legal and ethical thing to do. However, transparent communication is what publicly demonstrates a commitment to customer privacy and helps build brand credibility in an increasingly competitive market. Here are some communication best practices:

Streamline insurance underwriting with Apryse's flexible and customizable Document Generation Solution.

Redaction technology has come a long way since the “marker and tape” days. But not all redaction tools are created equally. If you’re looking for secure solutions to enhance customer trust, here are a few features to keep in mind.

Placing a black rectangle over sensitive text or images in a PDF only adds an extra layer over what you’re trying to redact. This layer can easily be removed, so it’s not secure. The Apryse WebViewer redaction tool completely and permanently removes the data. When it’s gone, it’s gone for good. (And it’s still as easy as drawing a rectangle.)

What makes it permanent is that the apply step destroys the content inside the marked region rather than covering it, and the destroyed content is not hidden behind a clipping path or an image mask. Marking content for redaction is reversible; applying it is not, which is why a review step belongs before the apply step and not after it.

In addition to the content you can see, documents can also have metadata like timestamps, revision history, and author names. This metadata could potentially contain sensitive details that shouldn’t be shared with unauthorized users.

Metadata is a separate problem from redaction, and a separate operation. Redaction removes visible page content. Metadata, XFA and XMP data, embedded scripts, form data and hidden layers are removed by sanitization, which is included in the base Apryse Server SDK package. A statement that has been redacted but not sanitized can still carry the account holder’s name in its document properties, so before a financial document leaves the institution both operations usually have to run. See redaction versus sanitization and PDF sanitization.

Time is money in the finance sector. Using the WebViewer SDK to automate redaction workflows means sensitive information can be detected and marked quickly, so each document reaches a reviewer already prepared. For bulk runs across large repositories, the Apryse Server SDK handles the same workflow headlessly.

Automated detection works by pattern. Ambient string matching, wildcards and regular expressions cover the structured identifiers that dominate financial documents: account numbers, card numbers, IBANs, sort codes and tax identifiers. Free-text fields and handwritten entries do not match reliably, which is where a review step earns its cost.

Legacy documents and formats can be a lingering challenge for financial institutions. Apryse WebViewer supports automated redaction for over 30 different document types, including PDFs, Microsoft Office files, and more. When it comes to security and redaction, leave no document behind.

Legacy archives are usually scans, and a scan has no text layer for a pattern to match against. Those documents go through OCR first and the recognized text is what detection searches, which means recognition quality sets a ceiling on redaction reliability. Handwritten entries on older forms need ICR rather than OCR. See redacting scanned documents.

Learn how some of Apryse’s redaction features work in this video:

A single KYC file is a review problem. An onboarding backlog is a throughput problem, and the two need different setups. Per-document review in the browser works when someone is looking at each file. A backlog of several thousand identity documents, proofs of address and source-of-funds records is a headless workload, and it runs on the Apryse Server SDK with no UI involved.

The sequence per document is the same either way: detect the identifiers by pattern, mark the matched regions, apply the redaction so the content is destroyed, then verify the output. What changes at volume is that verification has to happen per document rather than per batch. A batch-level check will tell you the run completed; it will not tell you that document 1,847 failed detection and went out with an unredacted account number. A per-document gate holds that file back instead.

One thing to plan for: the Apryse Server SDK provides no work queue, job scheduler or batch orchestration. It performs each document’s redaction headlessly, and the loop, the worker pool and the retry policy belong to your application. See redacting documents in bulk and server-side redaction in C#.

Statements are the easiest financial document to automate, because the identifiers in them are structurally regular. A pattern set built from ambient string matching, wildcards and regular expressions will reliably find most of what has to come out, and SSNs and credit card numbers are documented pattern examples in the SDK.

Three formats cause most of the misses. IBANs vary in length by country, so a single fixed-length pattern will silently skip entire markets. Card numbers appear spaced, hyphenated or run together, and a pattern written for one grouping will not match the others. And account numbers often share a shape with reference numbers, invoice numbers and sort codes, so a pattern tuned for recall will over-match and one tuned for precision will under-match.

For statements, tune for recall. An over-redacted statement is a re-run; an under-redacted one has already been sent. See PDF redaction and the compliance redaction process.

Redaction destroys content, and retention rules usually require the original to be preserved. Those two facts pull in opposite directions, and the workflow that resolves them is a retained original plus a redacted derivative, rather than redaction applied in place. The source document stays in the system of record; the redacted copy is what gets released.

That also means the same source can produce more than one derivative, each prepared for a different recipient with a different scope. A regulator, an external auditor and a third-party processor are not entitled to the same fields, and it is cleaner to generate three redacted copies than to negotiate a single lowest-common-denominator version.

The audit record should hold what was detected and by which rule, what a reviewer approved or rejected, when the redaction was applied, and the verification result. Once the content is gone it cannot be re-examined, so that record is the only remaining evidence of how the release was handled. See enterprise-grade redaction and keeping documents on your own infrastructure.

The Server SDK requires PDFNet.initialize() before any call and the Redaction Package on the production license key.

One asymmetry worth knowing when choosing: sanitization is Server SDK only. A browser-only integration can redact but cannot sanitize, so if hidden data has to be removed before release, the Server SDK has to be in the pipeline somewhere.

To learn more about other Apryse solutions for the fintech industry, visit our blog.

Build a pattern set and run it against the document text. Ambient string matching, wildcards and regular expressions cover the structurally regular identifiers that dominate statements, and the matched regions are then marked and the redaction applied. Watch IBAN country-length variation and spaced or hyphenated card groupings, which are the usual sources of a missed match.

Run the same detect, mark, apply and verify sequence over each document and verify per document rather than per batch, so a document that failed detection is held back instead of released with the rest. The Apryse Server SDK performs each document’s redaction headlessly; the queue, the parallelism and the retry policy belong to your application.

No. Redaction removes visible page content. Metadata, XFA and XMP data, embedded scripts, form data and hidden layers are removed by sanitization, which is included in the base Server SDK package. A redacted statement can still carry the account holder’s name in its document properties if it has not been sanitized.

Both are available. Browser-side redaction on the Web SDK suits per-document review before release. Server-side redaction suits onboarding backlogs, statement runs and archive remediation, where there is no UI and no one is looking at each file. Sanitization is Server SDK only.

By keeping the original and producing a redacted derivative, rather than redacting in place. Applying a redaction is irreversible, so a workflow that has to satisfy a retention obligation preserves the source document and releases the redacted copy.

What was detected and by which rule, what a reviewer approved or rejected, when the redaction was applied, and the verification result. Once the content is removed it cannot be re-examined, so that record is the only evidence of how the release was handled.

Not directly. A scan has no text layer for a pattern to match against, so it goes through OCR first and detection runs against the recognized text. Recognition quality therefore sets a ceiling on redaction reliability for archive material, and handwritten entries need ICR rather than OCR.

Three things are worth carrying out of this article. Removing and masking are not the same operation, and only one of them is redaction. Metadata is a separate operation on a separate surface, so a redacted document is not necessarily a clean one. And at volume, the verification gate belongs on each document rather than on the batch.

Discover how easy it can be to use redaction tools in our showcase.

Ready to add these capabilities to your document workflows? Start a Free Trial (Server SDK) for the KYC, statement and archive workflows, or Start a Free Trial (Web SDK) for in-browser review. No credit card required. You can also get in touch if you’d like to speak to a real human.

See also redaction use cases by industry.