Technical Paper - Bi-Directional Payment Integrity Network
FWEA Verdict Engine - The Payment Integrity Network
The system that decides if a payment should happen - before it happens. Unified coverage of Fraud + Waste + Error + Abuse.
69 signal checks across 9 weighted categories covering Fraud, Waste, Error, and Abuse (FWEA). Cryptographic verdicts issued before funds move. Post-quantum signed. Under-2-second latency. All payment rails including SEPA, UK FPS, PIX, UPI, SWIFT gpi, CIPS, NPP, and CBDC.
April 2026 - JIL Sovereign Technologies, Inc. - Patent Pending
Executive Summary
The JIL Pre-Settlement Fraud Attestation Engine is the Outbound Integrity component of JIL's Bi-Directional Payment Integrity Network - a centralized verdict service that evaluates every transaction before settlement occurs. Unlike post-settlement fraud detection (which identifies fraud after funds have already moved), JIL's engine issues a cryptographically signed verdict - YES, NO, or REVIEW - before any funds change hands.
The engine runs 37 independent fraud signal checks across 7 weighted categories in parallel, produces an aggregate risk score (0-100), and issues a signed attestation receipt. This receipt is immutable, timestamped, and stored on-chain - creating an auditable record that proves due diligence was performed on every single transaction.
The Three-Verdict Model
Every transaction receives exactly one of three verdicts, determined by the aggregate weighted score across all applicable signal categories:
| Verdict | Score Range | Action | Description |
|---|---|---|---|
| YES | 0-29 | Clear to settle | All fraud checks passed. Settlement proceeds immediately. Attestation receipt issued and published to Kafka for downstream consumers. |
| REVIEW | 30-70 | Hold for analyst | One or more signals triggered above threshold. Transaction held in escrow pending human review. Analyst sees full signal breakdown with recommended action. |
| NO | 71-100 | Block settlement | High-confidence fraud indicators detected. Settlement is blocked. Entity risk profile updated. SAR/CTR filing may be triggered automatically. |
How It Works
From transaction initiation to sealed attestation in four steps:
Transaction Initiated
A settlement request arrives via the Verdict API (POST /v1/verdict). The request includes sender/receiver identities, amount, currency, payment rail, and optional metadata (claim IDs, procedure codes, routing numbers). The engine assigns a unique verdict ID and timestamps the request.
37 Signals Scored in Parallel
All 7 signal categories are evaluated simultaneously using Promise.all(). Each category runs its checks independently - calling internal databases, upstream microservices (KYC, sanctions, compliance), and behavioral scoring models. No category waits for another. Total wall-clock time is determined by the slowest single category, not the sum of all checks.
Verdict Issued
Category scores are combined using a weighted average. Hard-block signals are checked. The engine produces a YES, REVIEW, or NO verdict with the full signal breakdown. The verdict, all signal scores, and entity risk profile updates are persisted to PostgreSQL.
Attestation Sealed
A SHA-256 attestation hash is computed over the verdict payload + cryptographic nonce. The attestation receipt is published to the fraud-verdicts Kafka topic for downstream consumption by the settlement consumer, compliance archives, and audit trail. The receipt is immutable - any attempt to alter the verdict would invalidate the hash.
9 Signal Categories (69 Checks - FWEA Coverage)
FWEA = Fraud + Waste + Error + Abuse. JIL is the only unified attestation engine that covers all four pillars of payment exposure as a single framework. The 9-category breakdown below includes 18 international rail checks (SEPA, UK FPS PSR, PIX, UPI, SWIFT gpi, CIPS, NPP, MiCA, DORA, FCA, FATF Travel Rule, IBAN, correspondent chain, FATF typology, Egmont FIU, BIS CPMI, cross-border velocity, hub routing) and 14 extended / emerging threat checks (pig butchering, AI voice deepfake, FaaS intelligence, DPAN wallet provisioning, Magecart, ZKP proofs, real estate wire protection, TBML, bust-out credit fraud, CBDC attestation, consortium intelligence, adversarial ML drift, HNDL quantum-safe TLS, XAI explanations). See the FWEA Framework and 69-Check Developer Reference for full details.
(Legacy note: the 7-category / 37-check framework described below is the original framing. The engine has since been extended to 9 categories / 69 checks. Each category has a weight that determines its contribution to the final aggregate score. Weights are configurable per deployment and can be adjusted by compliance officers via the Rules API.)
Each category has a weight that determines its contribution to the final aggregate score. Weights are configurable per deployment and can be adjusted by compliance officers via the Rules API.
| Signal ID | Check | What It Does | Data Source |
|---|---|---|---|
| ID-001 | UBO Verification | Queries KYC service for Ultimate Beneficial Ownership. Flags missing/stale UBO data, shell company indicators, circular ownership structures (recursive CTE graph traversal). | kyc-service |
| ID-002 | Synthetic Identity Detection | Scores identity authenticity based on SSN issuance date vs. stated age, address history depth, email domain age, phone carrier verification, and document anomaly patterns. | Internal + Experian CrossCore (vendor stub) |
| ID-003 | Account-to-Name Validation | Compares sender/receiver names against account holder names using Jaccard bigram similarity. Catches name mismatches that indicate unauthorized account use or account takeover. | Internal (Jaccard similarity) |
| ID-004 | Sanctions Screening | HARD BLOCK. Screens all parties against OFAC/SDN, EU Consolidated, UN Security Council, and OpenSanctions datasets. Any match produces an automatic NO verdict. Uses fuzzy matching (Levenshtein distance) for transliterated names. | sanctions-screening-cache |
| ID-005 | Deepfake/Liveness Detection | Stub for behavioral biometric verification. Will integrate with Sardine for device fingerprinting and behavioral analytics to detect session hijacking and deepfake authentication attempts. | Sardine (vendor stub) |
| ID-006 | Corporate Synthetic Fraud | Detects artificially created corporate entities: recently incorporated entities with no history, shared registered agent addresses, mismatched SIC/NAICS codes, and missing beneficial ownership filings. | Internal + OpenCorporates |
| Signal ID | Check | What It Does | Data Source |
|---|---|---|---|
| PR-001 | Business Email Compromise (BEC) | Detects BEC attacks: domain age <180 days, MX/SPF/DMARC failures, lookalike domain scoring (Levenshtein <3 vs. known counterparties), free email for business transactions, and domain typosquatting patterns. | kyc-service (RDAP/DNS) |
| PR-002 | Invoice Fraud Detection | Identifies invoice manipulation: amount significantly above historical average for the sender-receiver pair, sudden large increases, round numbers, and duplicate invoice references. | Internal (historical analysis) |
| PR-003 | Account Takeover (ATO) | Detects account takeover via impossible travel (login from two distant geolocations within an impossible timeframe), new device fingerprints, changed notification settings, and password-then-transfer patterns. | Internal + MaxMind GeoIP2 (vendor stub) |
| PR-004 | Processor Impersonation | Detects when a transaction claims to originate from a known payment processor but arrives from an unrecognized IP range or uses inconsistent processor metadata. | Internal |
| PR-005 | ACH Unauthorized Return | Scores sender based on historical ACH return rates. High unauthorized return rates (R05, R07, R10, R29) indicate potential unauthorized debit origination. | Internal (return rate analysis) |
| PR-006 | APP Scam Detection | Authorized Push Payment scam indicators: first-time payee, amount above normal, urgency metadata, social engineering indicators, and known scam typology patterns. | Internal + Feedzai (vendor stub) |
| PR-007 | Check Fraud (MICR/Image) | Validates check MICR line via Luhn checksum (ABA routing numbers). Detects duplicate check numbers, altered payee names, and MICR encoding inconsistencies. | Internal (Luhn/MICR validation) |
| PR-008 | Wire Transfer Anomaly | Detects suspicious wire patterns: first-time international wire, amount exceeds 3x the sender's 90-day average, intermediary bank in high-risk jurisdiction, and time-of-day anomalies (wires initiated outside business hours). | Internal |
| Signal ID | Check | What It Does | Data Source |
|---|---|---|---|
| RC-001 | Real-Time Sanctions | HARD BLOCK. Real-time screening against OFAC SDN, Consolidated, and Sectoral lists. Cross-references entity names, aliases, addresses, and ID numbers. Fuzzy matching with configurable threshold. | sanctions-screening-cache |
| RC-002 | AML Typology Matching | Detects three core AML typologies: (1) Round-trip transactions (funds return to originator via intermediaries), (2) Fan-out patterns (one sender to many receivers in short window), (3) Fan-in patterns (many senders to one receiver). | Internal (graph analysis) |
| RC-003 | OFAC Jurisdiction Risk | Scores transactions involving sanctioned jurisdictions (Iran, NK, Cuba, Syria, Crimea), high-risk jurisdictions (FATF list), and FATF grey-list countries. Separate severity tiers with different score impacts. | Internal (jurisdiction sets) |
| RC-004 | GENIUS Act Compliance | Validates stablecoin-specific compliance requirements per the GENIUS Act: issuer reserve attestation, redemption right verification, and custodial/non-custodial classification checks. | Internal |
| RC-005 | BSA/SAR Auto-Filing | Automatically flags transactions requiring Suspicious Activity Report (SAR) filing based on FinCEN guidelines. Tracks cumulative activity per entity for aggregate thresholds ($5K-$25K bands). | Internal (aggregate tracking) |
| RC-006 | CTR Detection | Currency Transaction Report detection for transactions exceeding $10,000 or structured patterns designed to evade the $10K threshold. Tracks 24-hour rolling aggregates per entity. | Internal ($10K threshold) |
| Signal ID | Check | What It Does | Data Source |
|---|---|---|---|
| VE-001 | Velocity Anomaly | Tracks transaction counts and volumes across three rolling windows: 1-hour, 24-hour, and 7-day. Flags when current velocity exceeds 3x the entity's established baseline. New entities (<30 days) receive elevated scrutiny. | Internal (rolling windows) |
| VE-002 | Mule Account Scoring | Composite score based on: rapid fund passthrough (receive-then-send within hours), multiple funding sources, account dormancy followed by sudden activity, and round-number transfers. | Internal |
| VE-003 | High-Volume Low-Value (HVLV) | Detects micro-transaction patterns used for money laundering: >50 transactions in 24h with individual amounts <$100. Commonly used to test stolen credentials or launder small amounts. | Internal |
| VE-004 | Smurfing/Structuring | Detects deliberate structuring to avoid the $10,000 CTR threshold: multiple transactions in the $8,000-$9,999 range within a rolling 24-hour window, especially across different accounts or branches. | Internal ($10K threshold) |
| VE-005 | Geographic Anomaly | Detects impossible travel and jurisdiction hopping: transactions from two geographically distant locations within an impossible timeframe, or rapid jurisdiction switching designed to exploit regulatory gaps. | Internal + IP geolocation |
| VE-006 | First-Party Fraud | Detects first-party fraud patterns: entities filing disputes on legitimate transactions, chargeback ratios above industry norms, and coordinated dispute filing patterns across related accounts. | Internal (dispute analysis) |
| Signal ID | Check | What It Does | Data Source |
|---|---|---|---|
| SI-001 | Routing Change Detection | Detects changes to settlement routing instructions (ABA number, SWIFT/BIC, account number) within the previous 72 hours. Any recent routing change triggers a mandatory 72-hour hold and elevated review. | Internal (change tracking) |
| SI-002 | Beneficiary Account Age | Scores the age of the beneficiary account. Accounts <30 days old receive elevated risk scores. Accounts <7 days old are flagged for review. Combines with velocity data for compound risk. | Internal |
| SI-003 | Instruction Provenance | HARD BLOCK on mismatch. Computes SHA-256 hash of the settlement instruction at initiation and compares it to the hash at settlement time. Any discrepancy indicates tampering between initiation and settlement. Uses Dilithium post-quantum signatures for hash verification. | Internal (SHA-256 + Dilithium) |
| SI-004 | Entity Credential Validation | Verifies sender and receiver credentials via the credential registry and compliance API. Checks credential expiration, revocation status, and issuer validity. | credential-registry, compliance-api |
| Signal ID | Check | What It Does | Data Source |
|---|---|---|---|
| HC-001 | Duplicate Claims | Detects three types of duplicate billing: exact duplicates (same claim ID), semantic duplicates (same provider + patient + service date + procedure), and cross-provider duplicates (patient billed by >3 providers on the same day). | Internal (claim analysis) |
| HC-002 | Provider Enrollment | Validates provider NPI (10-digit Luhn checksum with 80840 CMS prefix). Checks against internal exclusion list for debarred/excluded providers. Vendor stub for OIG/LEIE/SAM exclusion database integration. | Internal (NPI Luhn) + Streamline Verify (vendor stub) |
| HC-003 | Upcoding Detection | Identifies billing for higher-complexity procedures than historically supported: statistical outlier detection (amount >2.5 standard deviations above provider average), E&M code level analysis (99214/99215 usage rate >70%). | Internal (statistical analysis) |
| HC-004 | Remittance Mismatch | Compares expected remittance advice amount to actual payment. Flags variances >10% (moderate) and >25% (significant). Overpayments scored higher than underpayments due to higher fraud correlation. | Internal |
| HC-005 | Overpayment Recovery | Tracks providers with excessive overpayment patterns: >10 overpayments in 1 year triggers elevated scrutiny. Also checks for pending recovery actions that indicate ongoing investigation. | Internal |
| Signal ID | Check | What It Does | Data Source |
|---|---|---|---|
| SY-001 | Fraud Ring Detection | Graph analysis to identify coordinated fraud rings: clusters entities sharing IP addresses, device fingerprints, and account details. Two-hop analysis detects indirect connections. Clusters with >5 entities and >3 shared attributes trigger investigation. | Internal (graph clustering) |
| SY-002 | Typology Sharing | Cross-references detected patterns against known fraud typologies from FinCEN advisories, OCC bulletins, and internal pattern library. New typologies are automatically added when confirmed by analysts. | Internal + FinCEN advisories |
| SY-003 | Cross-Rail Correlation | Detects when the same entity or related entities conduct suspicious transactions across multiple payment rails simultaneously (e.g., wire + ACH + check in the same 24-hour window to the same beneficiary). | Internal (multi-rail analysis) |
| SY-004 | Four-Rail Coverage Verification | Ensures that every transaction is properly classified and routed through the appropriate rail-specific checks. Validates that Check, ACH, Wire, and Instant Payment transactions each receive their rail-specific fraud analysis. | Internal |
Weighted Scoring Model
Each category produces a score (0-100) based on the average of its triggered signal scores. The final verdict score is a weighted average across all categories with applicable signals:
| Category | Weight | # Checks | Rationale |
|---|---|---|---|
| Identity & Counterparty | 20% | 6 | Identity is the foundation. A compromised identity undermines all other checks. |
| Payment Rail-Specific | 20% | 8 | Rail-specific attacks (BEC, ATO, APP) represent the highest volume of real-world fraud. |
| Regulatory Compliance | 15% | 6 | Regulatory violations carry heavy penalties. Sanctions are hard-block automatic. |
| Velocity & Behavior | 15% | 6 | Behavioral anomalies detect novel fraud patterns that identity checks miss. |
| Instruction Integrity | 15% | 4 | Instruction tampering is the highest-value attack vector. Provenance is hard-block. |
| Healthcare & Government | 5% | 5 | Specialized rail with lower volume but significant government exposure. |
| Macro & Systemic | 10% | 4 | Cross-entity and cross-rail correlation detects coordinated attacks. |
Four-Rail Coverage
The OCC, Federal Reserve, and FDIC joint mandate requires institutions to have fraud controls across all four payment rails. JIL's engine covers all four with rail-specific signal checks:
| Payment Rail | Key Fraud Vectors | JIL Signals Applied |
|---|---|---|
| Check | MICR alteration, duplicate presentment, counterfeit, payee alteration | PR-007 (MICR/Luhn), HC-001 (duplicate detection), SI-001 (routing changes) |
| ACH | Unauthorized debits, return fraud, account validation, Nacha rule violations | PR-005 (unauthorized return), VE-001 (velocity), VE-004 (structuring), RC-006 (CTR) |
| Wire | BEC, instruction manipulation, intermediary routing, time-of-day anomalies | PR-001 (BEC), PR-008 (wire anomaly), SI-003 (provenance), SI-001 (routing change) |
| Instant / RTP | APP scams, velocity abuse, social engineering, account takeover | PR-006 (APP scam), PR-003 (ATO), VE-001 (velocity), VE-005 (geo anomaly) |
Cryptographic Attestation (Inbound Proof)
Every verdict produces a cryptographic attestation receipt - the Inbound Proof that completes the bi-directional integrity loop. This receipt serves as immutable proof that the transaction was evaluated and a decision was made before settlement, and proves the outcome after settlement. The attestation is:
- SHA-256 hashed: The verdict payload (transaction ID, verdict, score, timestamp, all signal scores) is hashed with a cryptographic nonce. Any alteration to the verdict data invalidates the hash.
- Post-quantum signed: The attestation hash is signed using CRYSTALS-Dilithium, a NIST-approved post-quantum digital signature scheme. This ensures the attestation remains tamper-proof even against future quantum computing attacks.
- Timestamped: ISO-8601 timestamp at the moment of verdict issuance. Combined with the hash, this creates a non-repudiable record of when the decision was made.
- Published to Kafka: The signed attestation is published to the fraud-verdicts Kafka topic for consumption by the settlement consumer, compliance archives, and real-time monitoring dashboards.
- Persisted to PostgreSQL: Full signal breakdown, entity risk profile updates, and the attestation receipt are stored in the fraud schema for audit and analytics.
Instruction Provenance (Dilithium-Signed)
One of JIL's most differentiated capabilities is instruction provenance attestation. This addresses the attack vector where a settlement instruction is modified between the time it is created and the time it is executed:
| Stage | What Happens |
|---|---|
| Initiation | When a settlement instruction is created, the engine computes a SHA-256 hash over the instruction fields (sender, receiver, amount, currency, routing details, reference). This hash is stored in the instruction_hashes table and signed with Dilithium. |
| Settlement | When the instruction arrives for settlement, the engine recomputes the SHA-256 hash over the same fields. If the recomputed hash does not match the stored hash, the instruction has been tampered with - the engine issues an automatic NO verdict (hard block). |
| Audit | Both the original hash and the settlement-time hash are stored, along with the Dilithium signatures. Auditors can independently verify that instructions were not altered. If a discrepancy is found, the system logs the exact fields that changed. |
Nacha 2026 Compliance
The engine is designed to meet Nacha's 2026 ACH fraud prevention requirements:
| Nacha Requirement | JIL Implementation | Signals |
|---|---|---|
| APP false-pretenses detection | APP scam detection with social engineering indicators and first-time payee flagging | PR-006 |
| Account validation for WEB debits | Account-to-name validation using Jaccard bigram similarity scoring | ID-003 |
| Unauthorized debit monitoring | ACH return rate tracking with R05/R07/R10/R29 code analysis | PR-005 |
| Large item fraud monitoring | Velocity anomaly detection with rolling windows, wire anomaly flagging for first-time large transfers | VE-001, PR-008 |
| Credit monitoring for originators | Mule account scoring with rapid passthrough detection and fan-out/fan-in analysis | VE-002, RC-002 |
Service Architecture
The fraud attestation engine integrates with JIL's existing microservice mesh:
| Upstream Service | What It Provides |
|---|---|
| kyc-service | UBO verification, BEC detection (RDAP, DNS, MX/SPF/DMARC), sanctions screening, identity verification |
| fraud-firewall | Real-time velocity scoring, sanctioned address checks, transaction blocking |
| compliance-api | Compliance zone routing, watchlist screening, regulatory jurisdiction classification |
| risk-scoring | Dynamic entity risk assessment, behavioral risk modeling |
| credential-registry | Party credential lookup, credential validity verification |
| sanctions-screening-cache | Cached sanctions results from OFAC/SDN, EU Consolidated, UN Security Council, OpenSanctions |
| policy-decision-api | Policy evaluation, rule-based decision logic, configurable thresholds |
API Reference
| Method | Endpoint | Description |
|---|---|---|
POST | /v1/verdict | Issue pre-settlement verdict. Returns YES/NO/REVIEW with full signal breakdown and attestation hash. |
POST | /v1/verdict/batch | Batch verdict for up to 100 transactions. Parallel processing with individual results. |
GET | /v1/verdict/:id | Retrieve a previously issued verdict by ID. Includes full attestation receipt. |
POST | /v1/signals/score | Score a single signal category independently. Useful for testing and debugging. |
GET | /v1/signals/categories | List all 9 categories with their 69 checks, weights, and current status. |
POST | /v1/instructions/hash | Register an instruction hash at initiation time (Dilithium signed). |
POST | /v1/instructions/verify | Verify instruction integrity at settlement time against stored hash. |
GET | /v1/rules | List all fraud rules with weights and thresholds. |
PUT | /v1/rules/:id | Update a rule's weight, threshold, or enabled status. |
GET | /v1/profiles/:entityId | Retrieve an entity's risk profile with score history and flagged signals. |
Competitive Differentiation
What makes JIL's Bi-Directional Payment Integrity Network fundamentally different from existing fraud detection:
- Bi-directional, not one-sided. JIL verifies before execution (Outbound Integrity) and proves after settlement (Inbound Proof). Together, this creates a continuous, closed-loop system of payment integrity that no single-direction system can match.
- Pre-settlement, not post-settlement. Every other major platform detects fraud after funds move. JIL blocks fraud before the settlement instruction executes. Recovery costs drop to zero because there is nothing to recover.
- Cryptographic attestation, not just a flag. Traditional systems set a flag in a database. JIL produces a SHA-256 hashed, Dilithium-signed attestation receipt that constitutes cryptographic proof of due diligence. This receipt is admissible, auditable, and tamper-evident.
- Post-quantum security. Dilithium signatures are NIST-approved for post-quantum resistance. JIL's attestation receipts remain valid and tamper-proof even against quantum computing attacks - a threat that will invalidate RSA and ECDSA signatures used by every existing system.
- Cross-rail correlation. JIL sees all four payment rails (Check, ACH, Wire, Instant). This enables detection of cross-rail fraud schemes where an attacker uses multiple rails simultaneously to evade rail-specific monitoring. No single-rail system can detect this.
- 37 parallel signals. All checks run simultaneously, not sequentially. This means sub-500ms verdicts despite 37 independent fraud checks - faster than most systems running 5 sequential checks.
- Instruction provenance. No existing system compares a cryptographic hash of the settlement instruction at initiation vs. settlement. This eliminates the highest-value attack vector: man-in-the-middle instruction modification.
- Nacha 2026 compliant out of the box. Full coverage of Nacha's 2026 ACH fraud requirements including APP false-pretenses, account validation, unauthorized debit monitoring, and large-item screening.
Data Model
The engine uses the fraud PostgreSQL schema with 7 tables:
| Table | Purpose | Key Columns |
|---|---|---|
fraud.verdict_requests | Incoming verdict requests | transaction_id, sender/receiver entities, amount, currency, rail_type, metadata (JSONB) |
fraud.verdict_results | Issued verdicts | verdict (YES/NO/REVIEW), score (0-100), attestation_hash, categories (JSONB), hard_blocks (array) |
fraud.signal_scores | Individual signal results | signal_id, signal_name, score, triggered (boolean), details (JSONB), source |
fraud.fraud_rules | Configurable rules | rule_id, name, category, weight, threshold, enabled, description |
fraud.entity_risk_profiles | Entity risk state | entity_id, risk_score, flags (JSONB), last_verdict, total_transactions |
fraud.instruction_hashes | Instruction provenance | instruction_id, hash (SHA-256), signature (Dilithium), fields_hashed (JSONB) |
fraud.instruction_changes | Routing change log | entity_id, field_changed, old_value, new_value, changed_at, hold_until |
Vendor Integration Roadmap
The engine is built with vendor-agnostic interfaces. Current vendor stubs return 501 with recommended integration partners:
| Vendor | Integration | Signals Enhanced | Status |
|---|---|---|---|
| Sardine | Device fingerprinting, behavioral biometrics, ATO detection | ID-005, PR-003 | Vendor stub |
| Feedzai / ComplyAdvantage | APP scam ML models, real-time transaction monitoring | PR-006 | Vendor stub |
| Plaid / Prometeo | Account ownership validation, balance verification | ID-003 | Vendor stub |
| MaxMind GeoIP2 | IP geolocation for impossible travel detection | PR-003, VE-005 | Vendor stub |
| Experian CrossCore | Synthetic identity scoring, credit header analysis | ID-002 | Vendor stub |
| Mastercard ACS | Account Confidence Score for real-time account validation | ID-003 | Vendor stub |
| Streamline Verify | OIG/LEIE/SAM provider exclusion database | HC-002 | Vendor stub |
Service: fraud-attestation-engine
Schema: fraud (7 tables, comprehensive indexes)
Dependencies: PostgreSQL, Redis, RedPanda (Kafka), upstream attestation services
API Proxy: /api/fraud
JIL Sovereign Technologies, Inc. - Patent Pending - April 2026
This document is confidential and proprietary.