Discover how LexisNexis Risk Solutions efficiently processes 50,000 documents daily using DocPath, balancing accuracy, speed, and compliance in high-volume document generation.
LexisNexis Risk Solutions generates approximately 50,000 documents per day with DocPath, which adds up to more than 15 million documents per year, and the operation has run in production since 2014.
LexisNexis Risk Solutions is a data and analytics provider for the insurance industry in the United States, and document creation and delivery sit at the center of what it does.
This post breaks down what high-volume document generation actually requires at that scale: how incoming data files trigger generation without human involvement, how parallel processing keeps batch windows short, why the environment runs on virtual machines instead of dedicated hardware, and which regulatory obligations shape document production for insurance and consumer data companies.
It also covers the limitation the case study documents openly, because more than a decade of production use surfaces trade-offs that no feature list will show you.
LexisNexis Risk Solutions needed a document platform that could sustain extreme daily volume without giving up accuracy, speed, or flexibility.
The company manages the creation and delivery of very large volumes of documents every day for insurance clients across the United States. Roughly 50,000 documents leave the platform daily. Over a year, that comes to more than 15 million. The daily print operation alone processes tens of thousands of pages in minutes.
Those numbers set the constraint. A platform that produces correct output at 500 documents per run is not automatically a platform that produces correct output at 50,000, because at production volume the cost of every small inefficiency multiplies, and the cost of every unhandled exception multiplies with it.
Three requirements shaped the decision: accuracy, speed, and flexibility. Accuracy because a document generated incorrectly at this scale is not one document to fix, it is a category of documents to fix.
Speed because the print operation runs against a fixed daily window. Flexibility because a document estate that serves insurance clients changes constantly, and a platform that requires vendor involvement for every template change becomes a bottleneck within months.
LexisNexis Risk Solutions selected DocPath and has been a client since 2014.
High-volume document generation fails differently from low-volume document generation, which is why platforms that perform well in a pilot often break once they carry real production load.
Start with the arithmetic of manual intervention. If one document in every thousand needs a person to review or correct it, a batch of 2,000 documents produces two exceptions per day and a batch of 50,000 produces fifty. Fifty exceptions per day is a full-time role that exists only because the platform cannot resolve them on its own. At 50,000 documents per day there is no team size that makes manual exception handling sustainable, so the generation process has to be correct by design rather than corrected after the fact.
Batch windows behave the same way. Print operations, mail handoffs, and downstream delivery all run against schedules that were set by business commitments, not by the platform. When generation takes longer than the window allows, the delay does not stay inside the document team. It moves into fulfillment, into customer communication timelines, and eventually into service level commitments with clients.
Failure modes also change shape. At low volume, a failed job is re-run and nobody notices. At high volume, a job that fails halfway through leaves a partially generated batch, and the operational question becomes which documents were produced, which were not, and whether re-running the job creates duplicates. Answering that question requires job-level monitoring and traceability, not just a generation engine.
There is one more difference that only appears in production. Throughput measured in a demonstration uses clean data and simple templates, while throughput in production absorbs template complexity, data quality problems, and output formats that were never part of the demonstration. The platforms worth evaluating are the ones that have already absorbed all of that somewhere else, at comparable volume, for long enough that the edge cases have surfaced.
DocPath supports the LexisNexis volume by detecting incoming data files automatically, generating documents in parallel, producing both PDF and large-format PCL output, and transferring the results to cloud storage containers.
Each of those four stages is a separate component in the DocPath suite, which is what allows any one of them to be scaled or reconfigured without rebuilding the others.
DocPath integrates with the LexisNexis systems to automatically detect incoming data files, which then become the trigger for document generation. Nothing waits for an operator to notice that a file has arrived.
In the DocPath suite, this is the job of DocPath InputAgent and DocPath JobProcessor. InputAgent captures data from the source system and triggers execution, scanning directories, pipes, output queues, and mainframe queues depending on how the source environment is built. JobProcessor orchestrates what happens next, including any pre-processing or post-processing steps that need to run around generation itself.
The practical effect is that the document pipeline inherits the schedule of the systems that feed it. When the upstream process finishes writing its data file, generation starts.
DocPath DocGeneration Engine, abbreviated as DGE, is the component that merges data with templates built in DocPath Designer and produces the finished documents.
DGE is built for parallel execution rather than sequential execution, which is the technical reason volume of this size is possible at all. The engine supports horizontal scalability through load balancers, and it runs under container managers and orchestrators including Docker and Kubernetes. A production environment that needs more throughput adds engine instances instead of waiting for a single instance to finish.
Integration happens through an HTTP REST API, where REST stands for Representational State Transfer, or through executable connectors for Windows, Linux, and IBM i. That matters for legacy environments, because it means the applications that hold the data do not need to be rewritten to feed the document platform. QBE took exactly that path when it migrated more than 6,000 business-critical forms to DocPath without modifying its core applications, with the system installed, tested, and ready within days.
The LexisNexis environment produces both PDF files and very large PCL files, where PCL stands for Printer Command Language.
Two formats from one generation run is a common requirement in operations that still carry a significant print component. PDF serves digital delivery, archival, and customer access. PCL feeds high-volume production printers directly, and for print runs of tens of thousands of pages, sending a print-native stream rather than converting page by page is what keeps the print window short.
DGE generates in PDF, PCL5, PCL6, AFP, PostScript, DOCX, HTML, EMF, ZPL, EPL, IGP, IPL, CSV, RTF, and TXT. Format coverage of that breadth is not a marketing checklist item in this context. It is what allows a single template estate to serve print, digital, and label output without maintaining parallel document systems.
Once generated, the documents are securely transferred to the LexisNexis cloud storage containers.
Distribution across channels is handled in the DocPath suite by DocPath ActiveSpooler, which can print, send by email, or store output files in external destinations, with a complete history of every action performed, including file format, timestamp, and destination. For organizations where the delivery event itself carries legal weight, this is also where certified email delivery fits into the same pipeline, producing evidence of delivery rather than just a sent record.
The LexisNexis document environment runs on virtual machines, which removes the need for dedicated hardware.
This is easy to read past, and it changes the economics of the whole operation. Dedicated hardware for document production has to be sized for peak load, which means it sits underused most of the time and still consumes capital budget, rack space, maintenance contracts, and a refresh cycle. Procurement adds months to any capacity decision.
Running on virtual machines moves capacity from a purchasing decision to a configuration decision. Combined with horizontal scalability and container orchestration, adding throughput becomes a matter of allocating more instances rather than ordering equipment. For an operation whose daily volume can shift with client activity, that is the difference between planning capacity annually and adjusting it when the workload changes.
It also removes an argument that frequently blocks modernization projects. Teams running legacy document platforms often assume that replacing them means a hardware program alongside a software program. The Reliable Parts project is a useful reference point here, since the company replaced JetForm with a cloud-ready document solution on Amazon Web Services rather than rebuilding an on-premises print environment.
A platform running the same critical operation since 2014 demonstrates something a product demonstration cannot, which is that it survived twelve years of changing requirements without being replaced.
Document estates do not stand still. Templates change, regulations change, output channels are added, upstream systems are upgraded, and volumes grow. A platform that cannot absorb those changes gets replaced, usually within a few years, and usually at significant cost. LexisNexis Risk Solutions describes DocPath as adapting to its evolving needs through configuration rather than redevelopment, and the client quote in the case study is direct about it: "DocPath is infinitely configurable, and the support staff are amazing to work with."
Support is part of that picture and is worth naming. At production volume, the response time on an issue is an operational number, not a customer service metric. A generation problem discovered at the start of a print window has to be resolved inside that window.
The case study is also honest about a trade-off, and it is worth repeating rather than hiding. The LexisNexis setup requires managing multiple file outputs manually, and the company identifies integrated file and form management as an area where further gains are available. That overhead has been judged acceptable against the flexibility and performance the platform delivers, but it is a real operational cost, and any organization evaluating a platform at this scale should ask where the equivalent manual step sits in its own design.
Document production for United States insurance and consumer data companies is governed by rules that apply to the content of individual documents and to the security of the systems that generate them.
The Fair Credit Reporting Act, abbreviated as FCRA, governs the content of specific documents. Under 15 U.S.C. §1681m, anyone who takes an adverse action against a consumer based in whole or in part on information in a consumer report must notify that consumer, and the notice has to include the name, address, and telephone number of the consumer reporting agency that furnished the report, a statement that the agency did not make the decision and cannot explain the reasons for it, and notice of the consumer's right to obtain a free copy of the file and to dispute its accuracy.
Every one of those elements is a field in a generated document. At scale, compliance depends on template governance and version control rather than on individual review, because nobody reads 50,000 notices before they go out.
The FTC Safeguards Rule, issued by the Federal Trade Commission under the Gramm-Leach-Bliley Act and codified at 16 CFR Part 314, governs the systems. Section 314.4(c)(3) requires customer information to be protected by encryption both in transit over external networks and at rest, unless the organization documents that encryption is infeasible and approves compensating controls in writing.
Section 314.4(c)(8) requires policies and controls that monitor and log the activity of authorized users and detect unauthorized access, use, or tampering. Section 314.4(f) requires oversight of service providers, including contractual obligations to maintain equivalent safeguards and periodic reassessment of those providers.
For insurance specifically, the National Association of Insurance Commissioners, abbreviated as NAIC, adopted the Insurance Data Security Model Law, known as Model #668, in October 2017. It requires licensees to develop, implement, and maintain a written information security program based on a risk assessment, with a designated individual responsible for it, and it explicitly extends the scope of that program to the licensee's use of third-party service providers. Model #668 has no force on its own and becomes binding only where a state adopts it, which means the applicable text is the state statute rather than the model itself.
Three obligations flow from all of this to whoever supplies the document platform. Data has to be encrypted in transit and at rest. System activity has to be logged in a way that can be reviewed. The supplier has to be able to evidence its own security posture, because the licensee remains responsible for it.
DocPath addresses these through an on-premises deployment approach that keeps client data inside client-controlled systems with no transfer to external DocPath servers, encryption of communications over HTTPS, support for current TLS versions for email, encrypted database connections, and encryption of documents and files stored on disk. Access control is configurable at the user and role level, and ActiveSpooler retains a complete history of every distribution action. On the organizational side, DocPath holds ISO 9001, ISO 27001, ISO 33000, and SOC 2 certifications, which are the artifacts a licensee will ask for when it assesses a third-party service provider under Model #668 or Section 314.4(f).
The questions that separate platforms at high volume are about architecture and operations, not about features, because most platforms will match each other on a feature comparison.
Ask about throughput under your own data, not under demonstration data. A vendor should be able to run a representative volume through a representative template and show the result.
Ask how generation is parallelized. If the answer involves a single process working through a queue, the ceiling is the speed of one process.
Ask which output formats are produced natively, because conversion steps between generation and delivery add both time and a failure point.
Ask how the platform integrates with the systems that hold the data. If integration requires changes to those applications, the project scope is much larger than the document platform.
Ask whether the platform runs on virtual machines and under container orchestration, or whether it assumes dedicated infrastructure.
Ask what job-level monitoring exists. When a batch fails partway through, the recovery path depends entirely on the visibility the platform provides.
Ask how templates are versioned. Regulatory content changes, and the ability to select a template by version and effective date is what keeps generation aligned with the rules in force at the time.
Ask where manual steps remain. Every real deployment has some, and the LexisNexis case is a good example of a platform being adopted with a known manual step rather than a claim that none exists.
Organizations working through a broader platform decision may also find the enterprise checklist for choosing a document management system in Latin America useful as a structured evaluation framework, since the selection criteria overlap substantially.
The LexisNexis Risk Solutions environment generates approximately 50,000 documents per day, or more than 15 million per year. DocGeneration Engine is designed for high-volume production in the range of tens or hundreds of thousands of documents per hour, and throughput scales horizontally by adding engine instances behind load balancers.
DocGeneration Engine produces PDF, PCL5, PCL6, AFP, PostScript, DOCX, HTML, EMF, ZPL, EPL, IGP, IPL, CSV, RTF, and TXT. The LexisNexis environment uses PDF and very large PCL files from the same generation process.
No. The LexisNexis environment is deployed on virtual machines with no dedicated hardware, and the platform supports container managers and orchestrators including Docker and Kubernetes.
It depends on the size and complexity of the document estate, but a large migration does not necessarily mean a long project. QBE migrated more than 6,000 business-critical forms without modifying its core applications, and the system was installed, tested, and ready to use within days, followed by training for the internal IT team.
The LexisNexis operation did not start at 50,000 documents per day. It started with a decision to move document production onto a platform built for that volume, and a plan for getting there without disrupting the business.
If your team is running a legacy document platform and working out what a move would involve, the JetForm Migration Checklist gives you the structure for that plan. It covers what to inventory and validate before the migration, what to control during it, and what to verify once the new platform is in production. The phases apply to any legacy document platform, not only to JetForm.
Sanitas uses document management solutions to download documents and generate any type of document online from BravoWeb, Sanitas new transaction...
The concept of 'document production software' is closely related to high volume document production environments.
With the new Document Software high-volume production of business documents increased 300% and generation of complex documents has incremented 40%