What is carrier ACH payment diversion fraud?

A form of business email compromise (BEC) in which fraudsters impersonate a legitimate motor carrier, request an urgent change to the direct-deposit banking information on file with the freight broker, and then divert settlement funds to a fraudulent account.

How does a bank account change verification engine protect freight brokers?

The engine locks all pending remittances to the carrier upon receipt of a bank change request, requires multi-factor out-of-band telephone confirmation using the FMCSA-registered phone number, performs OCR validation of a voided check against authoritative routing databases, and only releases the lock after all verification steps succeed.

Why is out-of-band telephone verification required?

Email accounts are frequently compromised. Out-of-band verification using a trusted, FMCSA-verified telephone number creates a separate communication channel that fraudsters cannot control even when they control the carrier's email.

Freight Broker Payment Security: Carrier Bank Account Change Verification Engines

Business Email Compromise (BEC) attacks targeting freight settlement processes continue to grow in sophistication and financial impact. Fraudsters compromise a motor carrier's email account, monitor load boards or EDI feeds for high-value freight movements, then submit an urgent request to change the carrier's ACH direct-deposit routing and account numbers immediately before settlement disbursement. Without robust automated controls inside the Transportation Management System (TMS), these requests can result in six- and seven-figure losses within hours.

This technical authority guide details the engineering patterns, database schemas, workflow orchestration, and compliance controls required to deploy a carrier bank account change verification engine that prevents unauthorized payment diversion while preserving operational velocity for legitimate carriers.

The Threat: Carrier Payment Diversion via BEC

Fraud actors leverage publicly available FMCSA data (MC number, USDOT number, carrier name, operating authority status) combined with social engineering to gain initial access to a carrier's email. Once inside, they monitor inbound settlement notifications or outbound load tenders. When a high-value load approaches the payment window, they send a professionally worded request to update banking information, often citing a "recent bank merger," "new account for faster processing," or "fraud on the old account."

Traditional manual review processes fail under volume. A mid-sized freight broker processing 800-1,200 carrier settlements per week cannot afford to delay every payment for manual verification. Automated verification engines solve this by applying risk-based decisioning and multi-factor controls only when a bank account change is requested.

TMS data desk showing carrier packet verification workflow

Core Architecture of a Carrier Bank Account Change Verification Engine

A production-grade verification engine is implemented as a state-machine service within or alongside the primary TMS. The engine maintains a strict separation of concerns between the carrier master data store, the remittance lock service, the verification orchestration layer, and the payment execution gateway.

Key System Components

Carrier Master Repository: Normalized PostgreSQL or SQL Server schema holding static carrier identifiers, FMCSA-sourced contact data, and historical banking records.
Remittance Lock Service: Distributed lock (Redis or database row lock) that prevents any ACH or check generation for a specific carrier until verification completes or is explicitly released by an authorized operations manager.
Verification Orchestrator: Workflow engine (temporal.io, Camunda, or custom Node.js/TypeScript state machine) that sequences multi-factor steps.
Document Intelligence Layer: OCR + computer vision service that parses VOID checks and extracts routing/transit numbers, account numbers, and account holder name.
Authoritative Validation Service: Integration with routing number databases (ABA, Federal Reserve, or commercial providers such as Accuity) and FMCSA API for phone and authority validation.

Simplified Database Schema - Carrier Banking Verification
Table	Key Columns	Purpose
carriers	carrier_id, usdot, mc_number, legal_name, verified_phone, verified_email, last_verified_at	Core carrier master with FMCSA-sourced data
carrier_bank_accounts	bank_account_id, carrier_id, routing_number, account_number, account_type, account_holder_name, status (active\|pending\|locked\|rejected), verified_at, verified_by	Historical and current banking records with audit trail
bank_change_requests	request_id, carrier_id, requested_routing, requested_account, requested_by_email, request_timestamp, current_status (received\|locked\|phone_pending\|ocr_pending\|approved\|rejected), lock_expires_at	State machine for each change request
verification_steps	step_id, request_id, step_type (phone\|ocr\|manual\|api), outcome, performed_at, performed_by, evidence_json	Audit log of every verification action

Automated Multi-Factor Verification Workflow

When a carrier submits a bank account change request (via carrier portal, email parsed by TMS, or EDI 210/214 context), the verification engine immediately:

Creates a new record in bank_change_requests and sets current_status = 'locked'.
Places a logical lock on all pending and future remittances for that carrier_id until the request is resolved.
Initiates an out-of-band telephone verification call or SMS to the FMCSA-registered phone number stored in the carriers table. This number must never be updated via email request.
Requires the carrier representative to confirm the request using a one-time code or by answering specific questions tied to the most recent load (e.g., "What is the PRO number of the load you delivered on March 28?").
Upon successful voice confirmation, triggers the document upload step for a VOIDED check or official bank letter.
Performs OCR parsing of the uploaded document, extracting routing number (ABA), account number, and account holder name.
Validates the routing number against an authoritative database and performs a name match (minimum 85% Levenshtein similarity after normalization) between the document and the carrier legal name on file.
If all automated checks pass, the engine updates the primary bank account record, releases the remittance lock, and notifies accounting that payments may resume.

Any failure at any step routes the request to a senior operations queue for manual review. All steps are logged immutably for regulatory and insurance purposes.

Intermodal drayage operations using secure TMS payment controls

Regulatory Compliance and Integration Best Practices

The verification engine must maintain alignment with FMCSA data (via API or daily batch), NACHA Operating Rules for ACH, and internal SOX-style controls for financial operations. Key integration points include:

Daily FMCSA synchronization of carrier contact information to ensure the verification phone number remains authoritative.
Integration with the brokerage's transportation accounting integration layer so that the ERP or accounting system respects remittance locks.
EDI 820/EDI 821 remittance advice workflows that include a verification status flag when sending payment confirmations back to carriers.
Audit-ready logging that satisfies both insurance carrier requirements and potential regulatory inquiry under the Bank Secrecy Act or state money transmitter rules.

Strong Tower Consulting recommends implementing this engine as part of a broader TMS implementation or business process optimization initiative. The same architecture supports additional controls such as velocity checks on bank changes (maximum one change per 90 days without escalated review) and geofencing of IP addresses used to submit changes.

Protect Your Settlement Process

If your brokerage or 3PL is experiencing increased volume of bank change requests or wants to evaluate the technical architecture of your current TMS payment controls, Strong Tower Consulting can perform a targeted security and workflow assessment.

Request a Payment Security Assessment or Contact Strong Tower Consulting at 763-244-1373