PRIVILEGED & CONFIDENTIAL ATTORNEY-CLIENT PRIVILEGED / ATTORNEY WORK PRODUCT PREPARED AT THE DIRECTION OF COUNSEL
CALDERWOOD & HARKNESS LLP Counselors at Law
OFAC REMEDIATION TESTING PLAN
Prepared for: BELMONT RIDGE BANK NATIONAL ASSOCIATION OCC Charter No. 48271
In Connection With: OCC Consent Order No. OCC-2025-003 (Effective January 15, 2025)
C&H Matter No.: 1045-00002
March 2025 (Draft for Ongoing Refinement Through November 1, 2025 Compliance Deadline)
Right-click to update Table of Contents
I. Executive Summary
This OFAC Remediation Testing Plan (the "Testing Plan" or "Plan") sets forth the comprehensive framework for the independent validation that one hundred percent (100%) of Banking-as-a-Service ("BaaS") transactions processed through Belmont Ridge Bank National Association ("BRB" or the "Bank") are screened against all applicable Office of Foreign Assets Control ("OFAC") sanctions lists following the remediation of the deficiencies identified in OCC Consent Order No. OCC-2025-003, issued by the Office of the Comptroller of the Currency (the "OCC") and effective as of January 15, 2025 (the "Consent Order"). This Plan has been prepared by Calderwood & Harkness LLP ("C&H") at the direction of the Bank's Chief Compliance Officer and BSA Officer and is subject to attorney-client privilege and the protections of the attorney work product doctrine.
The primary objective of this Testing Plan is to confirm the complete elimination of the OFAC sanctions screening gap that resulted in approximately 3,800,000 unscreened NovaPay Technologies Inc. ("NovaPay") transactions out of a total of approximately 31,700,000 NovaPay transactions processed through the Bank's charter during calendar year 2023, representing an approximately 12.0% failure rate. This screening failure constituted a significant violation of the Bank's obligations under 31 C.F.R. Part 501 and the Bank's own OFAC Compliance Policy and exposed the Bank to substantial enforcement risk under OFAC's strict liability framework.
The scope of this Testing Plan extends beyond NovaPay to encompass all fourteen (14) active BaaS fintech partner channels through which the Bank processes transactions. While NovaPay was the specific subject of the Consent Order's findings regarding the 12% screening gap, the OCC also identified inadequate OFAC screening across other BaaS partners, and this Plan is designed to provide comprehensive assurance that all BaaS channels are subject to complete OFAC screening coverage.
The Consent Order establishes a compliance deadline of November 1, 2025, by which date OFAC screening must be fully operational for all BaaS channels. This Testing Plan is designed to ensure that the Bank meets this deadline and can demonstrate compliance through rigorous, documented, and independently validated testing.
The Testing Plan is designed to support the following deliverables and milestones:
(a) Thornfield Consulting Group LLC's Independent Assessment and Final Validation Report, due February 15, 2026. Thornfield has been engaged by the Bank as the independent consultant required under the Consent Order, and the testing results generated under this Plan will form a critical component of Thornfield's final report to the OCC.
(b) Quarterly Progress Reports to the OCC, due September 15, 2025 and December 15, 2025. Testing results will be incorporated into these required progress reports, which will be submitted to the OCC Northeastern District Office.
(c) BRB's Self-Certification, due February 15, 2026. The Bank's self-certification that it has achieved compliance with the Consent Order's OFAC-related requirements will be supported by the comprehensive testing record compiled under this Plan.
This Plan covers three distinct but sequential phases of testing: (i) pre-deployment validation, encompassing testing during the implementation and user acceptance testing of Veridian Analytics Inc.'s ("Veridian") Transaction Monitoring System ("TMS") version 10.0 and enhanced OFAC module; (ii) go-live validation, encompassing testing during the post-deployment period from August through October 2025; and (iii) ongoing post-implementation monitoring, encompassing testing from November 2025 through February 2026 to confirm sustained compliance.
The technology remediation underlying this Testing Plan is the upgrade from Veridian TMS v.8.3 to Veridian TMS v.10.0 with an enhanced OFAC module, pursuant to Statement of Work No. 4 under the amended Master Service Agreement between BRB and Veridian (Contract No. VA-BRB-2023-0044). The deployment target for completion of User Acceptance Testing ("UAT") and production deployment is August 1, 2025. The Plan also addresses contingency procedures in the event of technology failure or delay, including the potential engagement of Ridgeline Data Systems LLC as a backup vendor.
This Testing Plan is a living document that will be refined and updated as testing progresses through the November 1, 2025 compliance deadline and the February 15, 2026 final reporting date. Any material amendments to this Plan will require the written approval of the designated signatories and notification to the OCC as described in Section XII below.
II. Background and Regulatory Context
A. OCC Consent Order Findings — OFAC Screening Deficiencies
On January 15, 2025, the OCC issued Consent Order No. OCC-2025-003 against Belmont Ridge Bank National Association. The Consent Order was the culmination of a multi-year supervisory process during which the OCC identified increasingly serious deficiencies in the Bank's OFAC sanctions screening program, particularly with respect to transactions processed through the Bank's BaaS fintech partner channels.
The Consent Order specifically found that BRB's OFAC screening system failed to screen 100% of transactions processed through fintech BaaS channels, in violation of the Bank's obligations under OFAC regulations and prudent banking practices. The most significant finding involved NovaPay Technologies Inc., the Bank's largest BaaS partner by transaction volume. The OCC determined that approximately 12% of NovaPay wire and ACH transactions — approximately 3,800,000 transactions out of a total of approximately 31,700,000 NovaPay transactions — were not screened against OFAC sanctions lists during calendar year 2023. This screening gap was attributable to technical deficiencies in the integration between NovaPay's transaction submission systems and the Bank's OFAC screening engine, specifically involving certain ACH transaction codes and wire sub-type routing that were not captured by the screening queue within Veridian TMS v.8.3.
NovaPay Technologies Inc. is the Bank's largest BaaS partner by transaction volume, representing approximately 41% of total BaaS transaction volume. In calendar year 2024, NovaPay processed approximately $30.5 billion of the Bank's $74.3 billion in total BaaS volume. NovaPay's operations focus on consumer payments and peer-to-peer ("P2P") transfers, and the BaaS relationship involves approximately 2.1 million end-user accounts.
Beyond NovaPay, the Consent Order cited inadequate OFAC screening across other BaaS partners. The Bank maintains fourteen (14) active BaaS fintech partner relationships, and the OCC found that the Bank had not established sufficient controls to ensure that all transactions processed through these channels were subject to comprehensive OFAC screening. The OCC identified deficiencies in the Bank's oversight framework, including the absence of standardized integration testing requirements, the lack of routine transaction reconciliation between the core banking system and the OFAC screening engine, and inadequate monitoring of screening coverage rates.
The Consent Order also referenced the Bank's failure to adequately remediate a prior supervisory action. In November 2023, the OCC issued a Matter Requiring Immediate Attention ("MRIA") regarding OFAC screening gaps in the Bank's BaaS channels. The MRIA specifically directed the Bank to (i) conduct a comprehensive assessment of OFAC screening coverage across all BaaS partners, (ii) implement controls to ensure 100% screening coverage, and (iii) report the results of its remediation to the OCC within 120 days. The Consent Order found that the Bank's response to the MRIA was insufficient, noting that the Bank had failed to conduct the comprehensive assessment directed by the MRIA and had not implemented adequate controls to close the identified screening gaps.
B. OFAC Screening Statistics (Baseline — CY 2024)
The following statistics represent the baseline OFAC screening metrics for calendar year 2024, against which post-remediation performance will be measured:
• Total OFAC Screening Hits (CY 2024): 14,320 alerts generated by the Veridian TMS v.8.3 OFAC screening module across all BaaS partner channels.
• True Matches Requiring blocking/Rejection: 12 transactions were identified as true matches to entries on the Specially Designated Nationals and blocked Persons List ("SDN List") or other applicable OFAC sanctions lists during CY 2024. All 12 transactions were blocked and the required OFAC blocking reports were filed within the 10-business-day reporting window.
• False-Positive Rate: The false-positive rate for CY 2024 was approximately 99.9%, calculated as (14,320 − 12) ÷ 14,320 ≈ 99.916%. This exceptionally high false-positive rate indicates that the screening system's matching parameters are overly broad, generating a significant volume of alerts that require manual review without corresponding benefit to sanctions detection effectiveness. The high false-positive rate also imposes substantial operational burden on the Bank's compliance team.
• Total BaaS Transaction Volume (CY 2024): Approximately $74.3 billion across all 14 active BaaS fintech partners.
• BaaS-Related Suspicious Activity Reports (CY 2024): The Bank filed 2,108 Suspicious Activity Reports ("SARs") related to BaaS activities during CY 2024, out of a total of 3,847 SARs filed by the Bank during the same period. BaaS-related SARs thus represented approximately 54.8% of all SARs filed, a figure that underscores the disproportionate compliance risk associated with the BaaS business line relative to the Bank's traditional banking operations.
These baseline metrics will serve as the primary reference point for evaluating post-remediation screening performance. It is important to note that these statistics reflect the screening activity that did occur during CY 2024 and do not account for any transactions that may have bypassed the screening engine entirely. A critical objective of this Testing Plan is to ensure that post-remediation metrics capture the complete transaction universe.
C. Remediation Technology Platform
The Bank's OFAC screening remediation is centered on the upgrade of its transaction monitoring and sanctions screening technology platform provided by Veridian Analytics Inc.
Incumbent Vendor: Veridian Analytics Inc., located at 1900 Embarcadero Road, Suite 400, Palo Alto, California 94303. Veridian has served as the Bank's primary vendor for transaction monitoring and sanctions screening since 2018.
Current System: The Bank currently operates Veridian TMS v.8.3, which was last validated in March 2021 and last tuned in October 2022. The age of the current system and the lapse in routine validation and tuning contributed to the screening deficiencies identified in the Consent Order. Specifically, Veridian TMS v.8.3 was not configured to capture certain transaction types and routing paths introduced by BaaS partner integrations after the most recent tuning cycle.
Planned Upgrade: The Bank is upgrading to Veridian TMS v.10.0 with an enhanced OFAC module. This upgrade is being implemented pursuant to Statement of Work No. 4 under the amended Master Service Agreement between BRB and Veridian (Contract No. VA-BRB-2023-0044). The financial terms of the upgrade are as follows:
• One-time implementation cost: $2,800,000
• Incremental annual licensing: $1,900,000 per year
• New total annual contract value ("ACV"): $6,000,000 per year
The enhanced OFAC module in Veridian TMS v.10.0 includes updated fuzzy matching algorithms, expanded list coverage, real-time screening capabilities for all transaction types, improved API integration architecture for BaaS partner data feeds, and comprehensive audit trail functionality. The primary Veridian contact for the implementation is Priya Subramanian, Vice President of Client Solutions.
Contingency Vendor: In the event that Veridian is unable to deliver the upgraded system within the required timeline, the Bank has evaluated Ridgeline Data Systems LLC as a backup vendor. Ridgeline is located at 500 West Monroe Street, Suite 2800, Chicago, Illinois 60661, and the Bank's primary contact is David Marchetti, Chief Revenue Officer. Ridgeline has proposed a five-year engagement at an annual cost of $7,200,000 ($36,000,000 total contract value). While the Ridgeline option represents a significantly higher cost, it provides the Bank with a viable alternative to ensure that the November 1, 2025 compliance deadline is met regardless of Veridian's performance. The contingency procedures governing the potential transition to Ridgeline are described in Section X of this Plan.
D. Key Deadlines Governing Testing
The following deadlines govern the testing activities described in this Plan:
Each of these deadlines has been incorporated into the testing schedule set forth in Section VIII of this Plan. The testing methodology and activities have been designed to generate the results and documentation necessary to support each of these deliverables on or before their respective due dates.
E. Responsible Parties
The following individuals and entities bear primary responsibility for the activities described in this Plan:
Calderwood & Harkness LLP:
• Philip Hartmann, Responsible Partner — Strategic oversight of the Testing Plan; primary liaison with the OCC and Thornfield Consulting on OFAC remediation matters; signatory on OCC submissions.
• Yuki Nakamura, Lead Associate — Day-to-day management of Testing Plan execution; review of testing results and deficiency reports; coordination of workstream activities.
• Carlos Espinoza, Working Associate — Coordination with Veridian Analytics on technical testing matters; drafting of testing reports and OCC submissions; deficiency tracking and documentation.
Belmont Ridge Bank National Association:
• Patricia Langston, Chief Compliance Officer — Executive sponsor of the OFAC remediation program; responsible for reporting results to the Compliance Committee and the Board of Directors.
• Thomas Ikeda, BSA Officer / AML Program Director — Overall accountability for OFAC screening program effectiveness; sign-off authority on testing results; escalation point for confirmed OFAC matches.
• Warren Ashby, Head of Fintech Partnerships / BaaS Division — Coordination with BaaS partners on data feeds, integration testing, and partner cooperation requirements.
• Linda Petrosian, Chief Information Officer / Chief Technology Officer — Oversight of technical implementation and UAT of Veridian TMS v.10.0; responsibility for system performance metrics and technology infrastructure.
Thornfield Consulting Group LLC:
• Dr. Vivian Castellano, Managing Director, Engagement Lead — Independent oversight of OFAC remediation testing as part of the comprehensive program assessment required by the Consent Order (Thornfield engagement reference: TCG-BRB-2025-001).
• Jennifer Hwang, Director, Sanctions & OFAC Compliance — Primary Thornfield lead for OFAC-specific testing validation; reviews testing methodology, results, and deficiency classifications.
• Nathaniel Burgess, Director, Fintech & Payments Compliance — Reviews BaaS partner-specific integration testing and partner cooperation compliance.
III. Scope of Testing
A. Transaction Types in Scope
This Testing Plan covers all transaction types processed through the Bank's BaaS partner channels, without exception. The principle underlying this Plan is that every transaction processed through the Bank's charter, regardless of the originating fintech partner, transaction type, or payment rail, must be screened against all applicable OFAC sanctions lists prior to completion. The following transaction types are expressly within scope:
• Wire Transfers: Both domestic wire transfers (processed through Fedwire or CHIPS) and international wire transfers (processed through SWIFT or correspondent banking relationships). This includes both outgoing wires initiated by BaaS partner end-users and incoming wires received for the benefit of BaaS partner end-users.
• ACH Transactions: Both ACH credits and ACH debits processed through the Automated Clearing House network, including same-day ACH transactions and standard settlement ACH transactions. This category includes direct deposits, bill payments, account-to-account transfers, and all other ACH transaction codes utilized by BaaS partners.
• Card-Based Transactions: All debit card and prepaid card transactions processed through the Bank's card programs offered via BaaS partners, including point-of-sale purchases, ATM withdrawals, card-not-present transactions, and card-to-card transfers.
• Peer-to-Peer (P2P) Transfers: All P2P payment transactions initiated through BaaS partner platforms, including instant transfers and scheduled transfers.
• Loan Disbursements and Repayments: All loan origination disbursements, draw-downs, and repayment transactions processed through BaaS partner lending platforms, including small-business loan disbursements, personal loan disbursements, and associated repayment flows.
• Deposit Account Transactions: All deposit account funding transactions, withdrawals, and internal transfers processed through BaaS partner digital banking platforms.
The scope encompasses both real-time transactions — including wires, P2P transfers, and card authorizations that require instantaneous or near-instantaneous screening — and batch-processed transactions — including ACH transactions, certain loan disbursements, and other transactions processed in periodic batch cycles.
The scope further encompasses both inbound and outbound transaction flows. Inbound transactions (e.g., incoming wires, incoming ACH credits) must be screened to identify potential sanctions exposure associated with the originator or originating institution. Outbound transactions (e.g., outgoing wires, ACH debits initiated by end-users) must be screened to identify potential sanctions exposure associated with the beneficiary or receiving institution.
B. BaaS Partners in Scope
This Testing Plan covers all fourteen (14) active BaaS fintech partners through which the Bank processes transactions. Testing will be conducted on a partner-specific basis — not aggregated across partners — to ensure that no individual channel has unscreened transactions. This approach reflects the OCC's findings that screening gaps were concentrated in specific partner integrations and that aggregate-level monitoring was insufficient to detect partner-specific deficiencies.
The following partners represent the Bank's top three BaaS relationships by transaction volume and are subject to enhanced testing focus:
1. NovaPay Technologies Inc.
• Chief Executive Officer: Ethan Garrison
• Address: 450 Mission Street, Suite 1200, San Francisco, California 94105
• Share of BaaS Transaction Volume: Approximately 41% (~$30.5 billion in CY 2024)
• End-User Accounts: Approximately 2.1 million
• Primary Business Line: Consumer payments and P2P transfers
• Relevance to Testing Plan: NovaPay is the source of the identified 12% OFAC screening gap cited in the Consent Order. Approximately 3,800,000 NovaPay transactions were unscreened during CY 2023. NovaPay will be subject to the most intensive testing under this Plan, including enhanced sampling (150% of standard sample size) during the first six months post-go-live.
2. FairLend Digital LLC
• Chief Executive Officer: Aisha Okonkwo
• Address: 100 Summer Street, Suite 800, Boston, Massachusetts 02110
• Share of BaaS Transaction Volume: Approximately 28%
• Loan Originations Through BRB (FY 2024): Approximately $1.4 billion
• Primary Business Line: Online small-business lending
• Relevance to Testing Plan: FairLend Digital's lending operations require screening of both borrower and beneficiary information. Loan disbursement transactions involve unique data fields and processing flows that require specific integration testing.
3. VaultEdge Inc.
• Chief Executive Officer: Marcus Tan
• Address: 2200 Ross Avenue, Suite 3600, Dallas, Texas 75201
• Share of BaaS Transaction Volume: Approximately 18%
• End-User Accounts: Approximately 870,000 deposit accounts
• Primary Business Line: Digital savings and neobanking
• Relevance to Testing Plan: VaultEdge's deposit account operations involve high-volume funding transactions, including external transfers and direct deposits, which require comprehensive screening at onboarding and on a transactional basis.
4. Remaining Eleven (11) BaaS Partners
The remaining eleven BaaS partners collectively represent approximately 13% of total BaaS transaction volume. Each of these partners will be subject to the full scope of testing described in this Plan, including partner-specific integration testing, transaction coverage reconciliation, and statistical sampling. The identities and specific details of these partners are maintained in the BaaS Partner Registry, which is incorporated by reference into this Plan and is available upon request.
C. OFAC Lists to Be Screened
The OFAC screening system must screen all in-scope transactions and customers/counterparties against the following OFAC-administered sanctions lists:
• Specially Designated Nationals and blocked Persons List ("SDN List"): The primary OFAC sanctions list, which identifies individuals and entities whose assets must be blocked and with whom U.S. persons are generally prohibited from dealing.
• Consolidated Sanctions List: OFAC's consolidated list that aggregates data from multiple sanctions programs into a single searchable resource.
• Sectoral Sanctions Identifications List ("SSI List"): Identifies persons operating in specific sectors of the Russian economy, subject to sectoral sanctions imposed under Executive Orders 13662 and 14024.
• Non-SDN Lists: Including but not limited to the Foreign Sanctions Evaders List ("FSE List"), the Palestinian Legislative Council List ("PLC List"), the List of Foreign Financial Institutions Subject to Correspondent Account or Payable-Through Account Sanctions ("CAPTA List"), the Non-SDN Menu-Based Sanctions List ("NS-MBS List"), and any other lists administered by OFAC that are applicable to the Bank's operations.
A critical element of the testing scope is the validation of OFAC list update ingestion. OFAC publishes updates to its sanctions lists on an irregular but frequent basis. The Veridian TMS v.10.0 system must ingest all OFAC list updates within twenty-four (24) hours of their publication by OFAC. Testing will validate that this requirement is met consistently throughout the testing period, as described in Sections IV.A.1, IV.A.2 (Scenario F), and IV.C.3 of this Plan.
D. Screening Processes in Scope
The following screening processes are within the scope of this Testing Plan:
• Customer/Counterparty Name Screening at Onboarding: Validation that all new customers onboarded through BaaS partner channels are screened against all applicable OFAC lists at the time of account opening or customer enrollment.
• Ongoing Customer/Counterparty Name Screening: Validation that existing customers are screened against updated OFAC lists on an ongoing basis, including upon each OFAC list update, to identify customers who may be added to sanctions lists after onboarding.
• Transaction-Level Screening: Validation that every individual transaction processed through BaaS partner channels is screened against all applicable OFAC lists, whether processed in real time or in batch mode. This is the core focus of this Testing Plan.
• Interdiction and blocking Procedures Upon Confirmed Match: Validation that the system correctly interdicts and blocks transactions that are confirmed matches to OFAC-listed persons or entities, preventing the completion of prohibited transactions.
• Hit Disposition and False-Positive Adjudication Workflow: Validation that all OFAC screening alerts (hits) are routed to qualified compliance personnel for review and disposition, and that the hit disposition workflow includes appropriate documentation, quality control, and escalation mechanisms.
• Escalation Protocols: Validation that potential true matches are escalated to the BSA Officer (Thomas Ikeda) and compliance leadership in accordance with the Bank's OFAC Compliance Policy, and that appropriate notifications to OFAC are made when required.
IV. Testing Methodology
A. Pre-Deployment Testing (Veridian TMS v.10.0 UAT Phase)
1. Unit Testing of OFAC Module
Prior to the commencement of user acceptance testing, Veridian Analytics Inc. will conduct internal unit testing of the enhanced OFAC module within Veridian TMS v.10.0. While unit testing is primarily a vendor responsibility, Calderwood & Harkness LLP will review and approve all unit test scripts prior to their execution to ensure that the test scenarios are sufficiently comprehensive to address the specific deficiencies identified in the Consent Order.
Fuzzy Matching Algorithm Validation. A critical component of unit testing is the validation of the upgraded fuzzy matching algorithm within the OFAC module. The unit test suite will include test cases designed to evaluate the sensitivity and specificity of the matching algorithm against known SDN entries with the following types of variations:
• Transliterations of names from non-Latin script languages (e.g., Arabic, Cyrillic, Chinese)
• Common misspellings and typographical variations of known SDN names
• Partial name matches (e.g., matching on surname only, or on partial first name)
• Name order reversals (e.g., "Last, First" versus "First Last")
• Use of aliases, also-known-as ("AKA") names, and doing-business-as ("DBA") names
• Entity name variations, abbreviations, and acronyms
• Matches against addresses in comprehensively sanctioned jurisdictions (e.g., North Korea, Iran, Cuba, Syria, and the Crimea region of Ukraine)
C&H will review the unit test results to confirm that the matching algorithm achieves an appropriate balance between sensitivity (the ability to detect true matches) and specificity (the ability to avoid false positives). The review will also confirm that the algorithm's matching thresholds are calibrated consistently with OFAC guidance on risk-based compliance program design.
List Ingestion Testing. Unit testing will also validate the system's ability to download and integrate all OFAC list updates within twenty-four (24) hours of OFAC publication. Veridian will conduct simulated list update scenarios in which test list files are published to the system and the system's ingestion and integration processes are verified. C&H will review the results to confirm that the system correctly parses list data, updates the screening database, and applies the updated list to all subsequent screening activities.
2. User Acceptance Testing (UAT) — Target Completion: August 1, 2025
User acceptance testing will be led by BRB's technology and compliance teams, with participation from Calderwood & Harkness LLP and Thornfield Consulting Group LLC. UAT is the critical pre-deployment testing phase during which the Bank will validate that the upgraded Veridian TMS v.10.0 system, including the enhanced OFAC module, performs as required in an environment that mirrors the Bank's production environment.
Test Environment Requirements. The UAT test environment must mirror the production environment for all fourteen (14) BaaS partner channel integrations. This means that the test environment must include:
• Functional API integrations with each of the 14 BaaS partner transaction submission systems (or, where live partner API connections are not feasible in the test environment, high-fidelity API simulators that replicate the data formats, transaction types, and routing behaviors of each partner's production systems)
• All OFAC sanctions lists loaded and current
• The complete fuzzy matching algorithm and matching threshold configurations intended for production deployment
• Production-equivalent hardware and network infrastructure to ensure that latency measurements are representative of production performance
Test Scenarios. The following test scenarios will be executed during UAT:
Scenario A — Transaction Screening Against Known SDN Entries. A minimum of five hundred (500) synthetic test cases will be submitted through each BaaS partner channel, totaling a minimum of 7,000 test cases across all 14 partners. Each test case will involve a transaction in which one or more fields (originator name, beneficiary name, originator address, beneficiary address) match or closely resemble a known SDN entry. The test cases will include exact matches, near matches, transliteration variants, alias matches, and partial matches. The expected result for each test case is that the screening engine generates an alert (hit) that is routed to the hit disposition queue.
Scenario B — Negative Testing. A minimum of one thousand (1,000) synthetic test cases will be submitted through each BaaS partner channel involving transactions with no OFAC nexus — i.e., transactions in which no field matches or closely resembles any entry on any OFAC sanctions list. The expected result for each test case is that the transaction passes through the screening engine without generating a false alert and without being improperly blocked. This scenario validates that the screening system does not impede legitimate transaction processing.
Scenario C — Batch Processing Validation. Simulated batch files will be submitted for ACH and loan transactions through each applicable BaaS partner channel. The batch files will contain a mix of transactions that should generate alerts and transactions that should not. The testing will confirm that 100% of transactions within each batch file are screened by the OFAC module, that alert-generating transactions are properly flagged, and that non-alert transactions are properly processed. The testing will also verify that batch file processing handles edge cases such as incomplete records, duplicate transactions, and transactions with missing or malformed data fields.
Scenario D — Real-Time Screening Latency Testing. For BaaS partner channels that process real-time transactions (wires, P2P transfers, card authorizations), the screening latency will be measured for each test transaction. The target screening latency is less than 500 milliseconds per transaction. Latency will be measured from the moment the transaction enters the screening queue to the moment the screening decision (pass or alert) is returned. Testing will include load testing at peak transaction volumes to ensure that the screening engine maintains acceptable latency under stress conditions.
Scenario E — Edge Case Testing. A dedicated set of edge case test scenarios will be developed and executed to validate the screening engine's performance in complex or ambiguous situations, including:
• Partial name matches where only a portion of the name matches an SDN entry
• Entity aliases and alternative name formats
• Addresses in comprehensively sanctioned jurisdictions where the transaction counterparty name does not match an SDN entry
• Multi-hop transactions (e.g., P2P transfers routed through intermediary accounts)
• Transactions involving high-risk jurisdictions that are not comprehensively sanctioned
• Transactions with non-standard characters, diacritical marks, or non-Latin script
Scenario F — OFAC List Update Propagation. A simulated OFAC list update will be introduced during the UAT period. The testing will validate that the new SDN entries are ingested by the system, integrated into the screening database, and applied to subsequent screening activities within twenty-four (24) hours of the simulated publication. The testing will also verify that existing customer databases are retroactively screened against the new entries within the system-defined service level agreement.
Pass/Fail Criteria. The following pass/fail criteria apply to UAT:
• 100% of test transactions must be screened. Zero unscreened transactions are permitted under any circumstances.
• All true positive test cases (Scenario A) must be correctly flagged as screening hits and routed to the hit disposition queue.
• All negative test cases (Scenario B) must pass through the screening engine without improper blocking.
• Batch processing (Scenario C) must achieve 100% screening coverage for all transactions within each batch file.
• Real-time screening latency (Scenario D) must not exceed 500 milliseconds per transaction under normal load conditions.
• OFAC list updates (Scenario F) must be ingested and applied within 24 hours.
• Any failure to meet the 100% screening coverage requirement or the true positive detection requirement constitutes a critical failure that must be resolved before deployment to production.
UAT Sign-Off. Formal sign-off on the UAT results is required from the following individuals before the system may be deployed to production:
• Linda Petrosian, CIO/CTO
• Thomas Ikeda, BSA Officer
• Patricia Langston, CCO
• Warren Ashby, Head of BaaS Division
3. Integration Testing per BaaS Partner
In addition to the cross-partner UAT scenarios described above, each of the fourteen (14) BaaS partner API integrations will be tested individually. The purpose of partner-specific integration testing is to validate the completeness and integrity of the data feed from each partner to the screening engine.
Transaction Data Feed Completeness. For each BaaS partner, the integration test will confirm that every transaction submitted by the partner through its API is received by the Veridian TMS v.10.0 screening engine. This will be accomplished by comparing the count and details of transactions submitted by the partner's API (as recorded in the partner's system logs or the Bank's API gateway logs) against the count and details of transactions received by the screening engine (as recorded in the screening engine's intake logs). Any discrepancy indicates a data feed integrity issue that must be investigated and resolved.
Transaction Type and Payment Rail Coverage. The integration test will confirm that no transaction type or payment rail processed by the partner is excluded from screening. This requires a comprehensive mapping of all transaction types and payment rails utilized by each partner against the screening engine's intake configuration. Any transaction type or payment rail that is not configured for screening constitutes a critical deficiency.
Enhanced Focus on NovaPay Integration. Given that NovaPay was the source of the identified 12% screening gap, the NovaPay integration test will include a detailed root cause analysis to confirm that the specific technical deficiency — whether it involved certain ACH transaction codes, wire sub-types, API routing failures, or other integration issues — has been fully remediated in the upgraded system. The root cause analysis will be documented in a separate memorandum prepared by C&H in coordination with Veridian and BRB's technology team. The integration test will include targeted test cases that replicate the transaction types and routing paths that were previously unscreened.
B. Go-Live Validation Testing (Post-Deployment, August – October 2025)
1. Parallel Processing Period
Following the deployment of Veridian TMS v.10.0 to the production environment, the Bank will conduct a minimum thirty (30) day parallel processing period during which all production transactions are processed through both the legacy Veridian TMS v.8.3 screening engine (if feasible to maintain in a parallel configuration) and the new v.10.0 screening engine. If full parallel processing is not technically feasible, a shadow testing approach will be employed in which all production transactions are processed through the v.10.0 screening engine and the results are compared against the screening results that would have been generated by the v.8.3 system based on historical data patterns and test replays.
The purpose of the parallel processing period is to identify any discrepancies between the old and new systems' screening behavior. Specifically, the reconciliation will focus on:
• Transactions that were screened by v.8.3 but not by v.10.0 (which would indicate a regression in the new system)
• Transactions that were screened by v.10.0 but not by v.8.3 (which would indicate that the new system is capturing transactions previously missed, as expected)
• Differences in alert generation between the two systems (which would indicate changes in matching algorithm sensitivity)
The results of the parallel processing reconciliation will be documented in a formal report that is reviewed by C&H and Thornfield.
2. 100% Coverage Confirmation Testing
The core go-live validation activity is the confirmation that 100% of BaaS transactions are screened by the upgraded OFAC module. The methodology for this confirmation is as follows:
Data Extraction and Reconciliation. For a defined test period of a minimum of five (5) consecutive business days per month during each of August, September, and October 2025, an independent data extraction will be performed to obtain the complete universe of BaaS transactions from BRB's core banking system. This extraction will capture every transaction processed through all 14 BaaS partner channels during the test period, regardless of transaction type, payment rail, or processing method.
The extracted transaction data will then be reconciled against the OFAC screening logs from Veridian TMS v.10.0. The reconciliation will confirm that every transaction identified in the core banking system extraction has a corresponding screening record in the OFAC screening logs. The reconciliation will be performed at the individual transaction level, using unique transaction identifiers to establish a one-to-one match between core banking records and screening records.
Reconciliation Dimensions. The reconciliation will be performed along the following dimensions:
• By BaaS Partner: Total transactions originated by each of the 14 BaaS partners must equal total transactions screened for that partner. Any partner-specific delta must be investigated and resolved.
• By Transaction Type: Total transactions of each type (wire, ACH credit, ACH debit, card, P2P, loan disbursement, loan repayment, deposit) must equal total screened transactions of that type. Any transaction-type-specific delta must be investigated and resolved.
• By Payment Rail: Total transactions on each payment rail (Fedwire, CHIPS, SWIFT, ACH, card network, internal) must equal total screened transactions on that rail. Any payment-rail-specific delta must be investigated and resolved.
Acceptance Criterion. The acceptance criterion is a 100% match rate — zero unscreened transactions. Any transaction identified in the core banking system extraction that does not have a corresponding screening record in the OFAC screening logs constitutes a critical deficiency that must be immediately escalated in accordance with the deficiency classification framework in Section VI.C of this Plan.
3. Hit Disposition Workflow Testing
During the go-live validation period, the testing will also validate the hit disposition workflow — that is, the process by which OFAC screening alerts are reviewed, investigated, and resolved by qualified compliance personnel.
The testing will confirm the following:
• All OFAC screening hits generated by the v.10.0 system are properly routed to the hit disposition queue for human review.
• The hit disposition queue is staffed by qualified compliance analysts who have received appropriate training on OFAC screening and hit disposition.
• Potential true matches are escalated to the BSA Officer (Thomas Ikeda) for review and determination.
• The blocking and rejection functionality operates correctly for confirmed SDN matches — that is, when a compliance analyst or the BSA Officer confirms that a transaction involves a person or entity on the SDN List, the system blocks the transaction and prevents its completion.
• Recordkeeping of hit disposition decisions is complete and accurate, including documentation of the analyst's review, the disposition decision (true match, false positive, or inconclusive), the basis for the decision, and the date and time of the decision.
• The system is capable of generating the required 10-day OFAC blocking report (OFAC Form TDF 90-22.50) for all blocked transactions, and that the report includes all required information.
The hit disposition workflow testing will include both review of actual production alerts during the go-live period and the introduction of synthetic test alerts to validate the workflow end-to-end.
4. False Positive Rate Analysis
During the initial go-live period, the testing will measure the false positive rate of the upgraded OFAC screening system and compare it against the CY 2024 baseline false positive rate of approximately 99.9% (14,308 false positives out of 14,320 total alerts).
A high false positive rate imposes significant operational burden on the compliance team and can degrade the quality of alert review if analysts are overwhelmed by the volume of alerts. Conversely, reducing the false positive rate by loosening matching parameters risks reducing detection sensitivity and allowing true matches to pass through undetected.
The testing will evaluate the tuning of matching parameters within Veridian TMS v.10.0 to optimize the balance between detection sensitivity and operational sustainability. The false positive rate reduction target will be established jointly by Thornfield Consulting (Jennifer Hwang) and BRB compliance leadership (Thomas Ikeda and Patricia Langston), with the overarching goal of maintaining or improving detection sensitivity while reducing the operational burden of false positive alert review. The specific target will be documented in a supplemental tuning recommendation memorandum.
C. Ongoing Post-Implementation Monitoring Testing (November 2025 – February 2026)
1. Monthly Transaction Coverage Reconciliation