PaperlayerView exact revision on arXiv

Source-linked AI summary

Spectra: A Rules-Driven LLM Pipeline for Automated KYC Document Processing

Miray Wahib, Ethan Tran, Rea Mourad, Mira Muti, Nikita Dvornik

arXiv:2609.25474v1cs.AI

TL;DR

KYC onboarding requires classifying documents, extracting fields, and checking complex policy requirements, creating substantial processing bottlenecks. Spectra pairs a queryable rules engine with isolated LLM agents and human review; it reports 100% classification accuracy on real KYC documents and 89.4% extraction accuracy on synthetic test documents.

  • Problem

    KYC onboarding involves classifying 20+ documents per case, extracting fields, and cross-referencing 400-page policies, with field extraction described as tedious and error-prone.

    Source: §1 · p. 1

  • Method

    Spectra encodes compliance policy in a queryable rules engine and uses isolated LLM agents for classification, extraction, and validation, with lower-confidence outputs routed for human review.

    Source: §1 · p. 2

  • Results

    Spectra reports 100% classification accuracy on real KYC documents and 89.4% extraction accuracy on synthetic test documents.

    Source: §1 · p. 2

  • Takeaways & Limitations

    The workflow keeps final approval with humans and surfaces lower-confidence extractions for review, aiming to reduce analyst burden while preserving auditability.

    Source: §1 · p. 2

    Hard schema enforcement is absent, and the current prompt does not adequately constrain the complex nested powers_to_bind field.

    Source: §3.4 · p. 6

Abstract

from arXiv · show

Know Your Client (KYC) onboarding in capital markets requires analysts to manually classify documents, extract structured data from heterogeneous sources, and validate compliance against complex regulatory policies. This process requires significant analyst time per client, with end-to-end onboarding often stretching to multiple weeks due to sequential handoffs. In this work, we analyze an on-boarding process and find that it comprises repeatable components well-suited to AI automation. We therefore propose a restructured workflow to be amenable to automation: we consolidate the traditional four-party process into two parties that share most of the work and can be automated together, eliminating intermediate handoffs that compound delays. To automate the remaining steps, we introduce Spectra, an AI-assisted document processing platform that combines a structured rules engine with LLM-based classification, extraction, and validation agents. The rules engine encodes compliance policy as a queryable database, enabling focused context injection that reduces token usage while improving extraction precision. Rather than a single monolithic prompt, the system decomposes document processing into isolated, auditable stages, each optimized independently and traceable to specific policy clauses. In evaluation on real KYC documents, Spectra achieves 100% classification accuracy and 89.4% extraction accuracy. Human review burden dropped by 96%.

1 Introduction

KYC onboarding combines document classification, field extraction, and policy validation across heterogeneous client requirements, creating substantial manual bottlenecks. Spectra addresses these tasks with a rules engine and isolated LLM stages, while retaining human review for lower-confidence outputs.

1 Introduction

  • 20+ documents per case must be classified across 50+ types, while field extraction and cross-referencing 400-page policy documents are tedious bottlenecks.Requirements vary by jurisdiction and entity type.Source: §1 · p. 1
  • A single monolithic LLM call cannot accommodate hundreds of policy pages, localize errors, or provide traceability to specific policy clauses.The paper motivates specialized stages with focused context and structured outputs.Source: §1 · p. 2
  • Spectra combines a queryable compliance rules engine with isolated LLM agents for classification, extraction, and validation.The system also reports an evaluation framework with per-field and per-document-type breakdowns.Source: §1 · p. 2
  • Spectra uses two teams: Gathering collects and processes documents, while Approval reviews flagged items and provides final sign-off.Extractions below 100% confidence are surfaced for human review to preserve auditability.Source: §1 · p. 2

2 Approach

Spectra combines a queryable rules engine with a staged document-processing pipeline and human review. Its workflow separates policy encoding from AI execution and supports independent optimization and auditability.

2.1 AI-Native KYC Workflow

  • The workflow places Intake, Coordination, and Processing in a shared Gathering workspace, then routes cases to Approval for exception review and final sign-off.Reviewers can approve or return cases with specific deficiencies.Source: §2.1 · p. 2, Figure 1 · p. 3

2.2 Problem Formulation

  • The automation is framed as classification, extraction of schema-defined fields with confidence, and validation of extracted data against applicable rules.Validation can pass, fail, or trigger an exemption that modifies the checklist.Source: §2.2 · p. 3
  • A naive all-in-one policy prompt exceeds context limits, obscures stage-specific errors, forces whole-pipeline retries, and weakens policy-clause traceability.The workflow instead divides work into separate tasks.Source: §2.2 · p. 3

2.3 Rules Engine Architecture

  • The PostgreSQL rules engine stores document, field, requirement, and exemption definitions for jurisdiction-, entity-, and product-specific requirements.Join tables encode relationships among documents, fields, and requirements.Source: §2.3 · pp. 3–4
  • The rules engine generates checklists deterministically and injects only relevant definitions, fields, and validation rules into LLM context.Checklist generation for a client’s jurisdiction, entity type, and product requires no LLM call.Source: §2.3 · p. 4

2.4 Multi-Agent Pipeline

  • Six isolated stages cover sanitization, injection detection, classification, deterministic schema lookup, extraction, and validation, enabling stage-specific optimization and auditability.The generated extraction schema combines document-type fields with fields required by the matched requirement; extraction returns field confidence and source evidence.Source: Figure 2 · p. 4, §2.4 · p. 4

2.5 Human-in-the-Loop Design

  • Spectra retains human final approval, surfacing sub-100%-confidence data points with source evidence and recording justifications for analyst overrides.The Approval Team retains final authority under the four-eye check principle.Source: §2.5 · p. 5
  • A controlled test reduced required review items from 206 to 8, a 96% reduction in manual verification workload.Data points at 100% confidence are auto-approved; lower-confidence points are flagged for human review.Source: §2.5 · p. 5

3 Evaluation

Spectra was evaluated for classification and extraction accuracy, with performance also examined by document type and field type. Classification was perfect across the tested document types, while extraction errors exposed schema and vocabulary constraints that need refinement.

3 Evaluation

  • The evaluation measured classification and extraction accuracy, then disaggregated extraction results by document type and field type to locate areas needing improvement.The classification corpus contained 21 real KYC documents spanning 9 document types; extraction used 15 synthetic documents with 141 annotated field values across 27 field types.Source: §3 · p. 5, §3.1 · pp. 5–6

3.2 Classification Results

  • All 9 document types achieved perfect precision and recall, and the classification agent achieved perfect accuracy on the test set.Table 1 reports document classification performance; 81% of documents were classified with 100% confidence and the remaining 19% with 95% confidence.Source: §3.2 · p. 6, Table 1 · p. 6
  • The classification results are limited by a small test set of 21 relatively clean PDFs and candidate-set filtering that may reduce effective difficulty.The authors call for evaluation on a larger, more diverse corpus including scanned documents with OCR artifacts.Source: §3.2 · p. 6

3.3 Extraction Results

  • 71 true positives, 55 true negatives, 11 false positives, and 4 false negatives made up the extraction confusion matrix.Extraction performance was evaluated on 15 documents with 141 annotated fields.Source: §3.3 · p. 6, Table 2 · p. 6
  • Type A corporate resolutions had the lowest extraction accuracy at 50%, with powers_to_bind extracted when the ground truth was null.The authors identify schema definition or prompt refinement as needed for this edge case.Source: §3.3 · p. 6, Table 3 · p. 7

3.4 Failure Analysis

  • Complex powers_to_bind structures can be inferred incorrectly when the field should be null, while products_product_type lacks a controlled vocabulary for matching expected taxonomies.Hard schema enforcement is not yet present; descriptive values such as “Private Equity” may differ from the expected taxonomy.Source: §3.4 · p. 6
  • The model sometimes over-extracts adjacent document fields that the extraction schema does not request, indicating insufficient schema constraints.Figure 3 contrasts schema-required fields with additional fields included in the actual extraction.Source: §3.4 · p. 7, Figure 3 · p. 8

4 Conclusion

Spectra combines a structured rules engine with LLM-based agents in isolated, auditable stages to process KYC documents. Challenges remain for some complex documents and fields, and evaluation on larger, more diverse corpora is still needed.

4 Conclusion

  • Spectra combines a structured, queryable compliance-policy database with LLM-based classification, extraction, and validation agents in isolated, auditable stages.The architecture is presented as achieving high accuracy while maintaining full auditability.Source: §4 · p. 8
  • Challenges remain for certain complex document types and fields, and the system needs evaluation on larger, more diverse document corpora.Source: §4 · p. 8
  • The rules engine can be extended without retraining models, while individual pipeline stages can be optimized independently.Source: §4 · p. 8

A Rules Engine Schema

Spectra’s rules engine represents KYC policy in a structured, queryable schema. Its entity-relationship design links documents, requirements, data fields, and exemptions.

A Rules Engine Schema

  • The schema encodes KYC compliance policy in a structured, queryable format, avoiding the need to pass hundreds of pages of policy documents to LLM agents.Source: A Rules Engine Schema · p. 9
  • Core tables define documents, requirements, data fields, and exemptions, while join tables encode many-to-many relationships among them.Source: Figure 4 · p. 9
  • The diagram distinguishes core tables in teal from join tables in white.Source: Figure 4 · p. 9

A.1 Core Tables

The rules engine’s core tables represent onboarding requirements, acceptable document types, extraction fields, and conditional exemptions. Together, they specify what is required and how it may be fulfilled.

A.1 Core Tables

  • Each doc_requirements row scopes an onboarding requirement by jurisdiction, entity type, and product type.Its is_baseline flag distinguishes standard requirements from conditional ones, and data_source specifies whether fulfillment uses client documents, a corporate registry, or both.Source: §A.1 · p. 9
  • The documents table defines acceptable document types and includes descriptions for classification and invalid_if rules for validation.Its data_source indicates whether a document typically comes from external sources, internal systems, or both.Source: §A.1 · p. 9
  • The data_requirements table defines fields to extract and supplies JSON schemas specifying expected structure, types, descriptions, and nested fields.The schema is passed directly to the extraction agent to ensure consistent output structure.Source: §A.1 · p. 9
  • The exemptions table links a triggering data field to a requirement that can be added or removed, with natural-language conditions evaluated by the validation agent.Source: §A.1 · p. 10

A.2 Join Tables

Three join tables connect requirements, documents, and data fields. Their links support alternative document types, fields inherent to a document, and requirement-specific extraction schemas.

A.2 Join Tables

  • acceptable_documents links requirements to the document types that can satisfy them, allowing one requirement to accept alternatives across jurisdictions.Source: §A.2 · p. 10
  • must_contain links fields to document types so fields inherent to an identified document are always extracted.For example, a Certificate of Incorporation must contain an incorporation date and entity name.Source: §A.2 · p. 10
  • doc_data_requirements links fields to requirements, allowing the same document type to use different extraction schemas depending on the requirement it fulfills.A Corporate Resolution may require signatories for one requirement or resolution details for another.Source: §A.2 · p. 10
Loading 2609.25474v1…