Client-Side Document Processing and Data Residency Explained

How does the document processing solution you choose affect data residency compliance?

Let’s start by defining these terms: data residency is the requirement that a document stay within a specific physical location and legal jurisdiction. This is the operational core of what lawmakers mean by data sovereignty. Data sovereignty, on the other hand, is the principle that a document is subject to the laws of the country where it is created, stored, or processed.

Client-side processing in the browser and self-hosted processing on your own servers satisfy these requirements because the document never travels to a third party's infrastructure in the first place. For a bank, insurer, or lender, this architectural choice helps ensure compliance.

Data sovereignty is a legal concept stating that data is governed by the laws of the country where it lives, not necessarily the laws of the country where the vendor processing it happens to be headquartered. For example, a loan file created and stored in Germany is subject to German and EU law, even if the software rendering it was built in California.

For software, data sovereignty is a compliance issue, especially during procurement processes. If you’re building a fintech platform that serves enterprises and organizations, you’ll have to meet not only your own industry’s compliance requirements, but also those of your customers, especially if your product serves a global market.

When it comes to document processing technology, building a seemingly innocuous workflow such as PDF conversion or digital signatures can risk breaking critical compliance in this area. Your architecture must account for where data is stored and processed at every step of the document lifecycle.

I’ve seen these three terms get used interchangeably in vendor content, but in reality, each term answers a different question.

This is a good question, because it may seem like as long as software developers know where data is stored and processed, data sovereignty will take care of itself. Unfortunately, this is not exactly the case.

Certain jurisdictions (the U.S., China, some others) have extraterritorial data access laws like the U.S. CLOUD Act. This law allows the U.S. Government to request or subpoena data stored in another country if the cloud provider is an American company.

One note here is that even if your data can be accessed, encryption prevents it from being read or extracted. Check out Apryse Encryption for more information.

Apryse WebViewer compiles its C++ document engine to WebAssembly and runs it inside the browser. When a document loads, viewing, annotation, redaction, and page manipulation all execute client-side, in the WASM module. There is no HTTP round trip to a document-processing server, and no document content transmitted to any Apryse infrastructure. From a residency standpoint, the browser tab is the entire processing environment: the document arrives from wherever your application serves it and never leaves the user's machine to be rendered.

This works well for a wide variety of document processing workflows, but for batch processing and data extraction, server-side computing muscle is needed.

You’ve already done the compliance assessments on your cloud provider. With Apryse Server SDK, your document processing runs in this environment with no external dependencies, or on-premise hardware, a cloud VM inside your own account, a container, or a fully air-gapped environment with no outbound network calls at all.

No document content is transmitted to Apryse or to any third party at any point in the pipeline. Because deployment is determined by your infrastructure choices rather than by Apryse, the same binary that runs in a VPC for one team can run fully offline for another.

With document processing workflows built using cloud APIs, you get your first result faster with low maintenance, but can’t control where document is stored or processed. This tradeoff could cause problems for data residency compliance.

Many of our customers build a hybrid architecture to handle a wide range of document processing capabilities across client side and server side. For example, WebViewer handles viewing, annotation, and redaction directly in the browser, while heavier processing like Smart Data Extraction runs on a self-hosted Server SDK instance inside the same infrastructure perimeter. With Apryse, both SDKs are designed to work together seamlessly, and you maintain control of the data.

For Fintech and Financial services, data sovereignty and data residency are critical compliance concerns.

Here are some examples of financial document workflows that can lead to non-compliance:

Secure Redaction is available in both the Server SDK and WebViewer. Redaction permanently removes sensitive information from documents. While some redaction workflows rely on third-party processing, Apryse keeps this sensitive process entirely within your environment.

Cloud document processing APIs from the major hyperscalers get a working prototype in front of stakeholders fast while they manage the scaling. Pay-as-you-go pricing is a good fit when volumes are low or unpredictable, but teams typically move away from this model when one of three things changes:

If you’re interested in using Apryse to improve you compliance posture, you can start with the WebViewer getting-started guide for client-side viewing, annotation, and redaction, or the Server SDK getting-started guide for self-hosted backend processing, including on-premise and air-gapped deployment.

Your trial key covers both SDKs and unlocks all our add-on modules like Smart Data Extraction for evaluation. For an architecture review specific to your residency or compliance requirements, contact sales.

What is data sovereignty? 

Data sovereignty is the legal principle that a document is subject to the laws of the country where it is created, stored, or processed, regardless of where the software touching it is based. It is a jurisdictional concept, distinct from data residency, which is the practical requirement for where a file is physically stored and processed.

Why does client-side processing improve security? 

Client-side processing removes an entire transmission step: the document never leaves the browser to be rendered, annotated, or redacted, so there is no network hop to a third-party server that could be intercepted, logged, or breached in transit. The attack surface shrinks because there is one less system, the vendor's servers, that ever has the document.

How can organizations process documents without third-party infrastructure? 

Two architectures make this possible. Client-side processing runs the document engine inside the browser via WebAssembly, so viewing and editing happen locally on the user's machine. Self-hosted server processing runs the same engine on your own servers, VPC, or air-gapped environment, so backend operations like extraction and conversion also never touch a third party.

What are the risks of sending documents to external services? 

The document transits infrastructure you do not control, which creates residency and sovereignty exposure the moment it crosses that boundary, even briefly. Per-page or per-call pricing also compounds at volume, and most hosted extraction services are probabilistic, which makes independently verifying correctness harder than with a deterministic process running in your own environment.

What is the difference between data sovereignty and data residency? 

Data sovereignty is the legal principle: a document is governed by the laws of the jurisdiction where it resides. Data residency is the practical, architectural answer to that principle: a requirement that the document be stored and processed in a specific location. Residency is how you satisfy sovereignty in practice.

What are the requirements for data sovereignty? 

Requirements vary by jurisdiction, industry, and data type, and they range from voluntary residency commitments to hard data localization mandates with no cross-border exception. Financial services requirements like DORA and SEC recordkeeping rules, and cross-industry regulations like GDPR and HIPAA, share a common thread: the ability to show which environment processed a document and that it stayed within the jurisdiction the rule specifies.

Why is data residency important for document processing? 

Because a document is a physical artifact with a location at every moment of its lifecycle, not an abstraction. Every time a document workflow sends a file to a third-party server, it creates a new location, and potentially a new jurisdiction, that has to be accounted for under residency and sovereignty rules. Architecture that keeps the document inside your own environment removes that exposure at its source instead of managing it after the fact.

How does client-side document processing support GDPR and DORA compliance? 

Client-side and self-hosted processing keep documents inside the environment the customer controls, which directly addresses the cross-border transfer restrictions in GDPR Article 44 and following, and the operational-resilience expectations DORA places on financial entities and their ICT providers. Because the document never transits third-party infrastructure, there is no transfer event to justify under either framework in the first place.