12.2 Defense-in-Depth: Positive Pay, Dual Approvals, Out-of-Band Callbacks & Tokens

12.2 Defense-in-Depth: Positive Pay, Dual Approvals, Out-of-Band Callbacks & Tokens

Executive Summary: Mitigating modern treasury fraud requires a multi-layered defense-in-depth architectural model. No single control—whether an IT firewall or an internal approval policy—is sufficient to prevent sophisticated attacks. Treasury teams must combine automated bank-provided validation tools (such as Payee Positive Pay, ACH Filters, and UPIC) with rigorous internal operational disciplines (Maker-Checker segregation of duties, out-of-band supplier callbacks, and hardware-authenticated token controls).

---

The Treasury Defense-in-Depth Model

In information security and financial controls, defense-in-depth is the practice of layering multiple defensive mechanisms so that if an attacker circumvents or breaches one layer, subsequent layers automatically intercept and neutralize the threat.

                         The Treasury Defense-in-Depth Architecture

  ┌─────────────────────────────────────────────────────────────────────────────┐
  │ Layer 1: Perimeter & Infrastructure Security                                │
  │ • Firewalls, TLS 1.3 Encryption, Host-to-Host (H2H) VPNs, IP Whitelisting  │
  ├─────────────────────────────────────────────────────────────────────────────┤
  │ Layer 2: Governance & Administrative Policies                               │
  │ • Treasury Management Policy Manual (TMPM), Annual Fraud Training, SoD SOPs │
  ├─────────────────────────────────────────────────────────────────────────────┤
  │ Layer 3: Internal Operational & Workflow Controls                           │
  │ • Maker-Checker Dual Approval, Mandatory Out-of-Band Callbacks, MVF Locks   │
  ├─────────────────────────────────────────────────────────────────────────────┤
  │ Layer 4: Bank-Provided Automated Fraud Services                             │
  │ • Payee Positive Pay, ACH Debit Blocks & Filters, UPIC Masking              │
  ├─────────────────────────────────────────────────────────────────────────────┤
  │ Layer 5: Post-Transaction Surveillance & Reconciliation                     │
  │ • Daily Automated BAI2/CAMT.053 Reconciliation, Real-Time Anomaly Alerts    │
  └─────────────────────────────────────────────────────────────────────────────┘

---

Bank-Provided Automated Fraud Detection Tools

Commercial banks provide specialized automated services designed to intercept unauthorized disbursements before funds leave the banking institution.

                              Bank Automated Fraud Prevention Services
                                                 │
         ┌──────────────────────────────┬────────┴────────────────────────┬─────────────────────────┐
         ▼                              ▼                                 ▼                         ▼
    Check Positive Pay        Payee Positive Pay                   ACH Debit Block           ACH Debit Filter
  • Matches Check # & Amount   • Matches Check #, Amount & Payee  • Prohibits ALL incoming  • Whitelists approved Company IDs
  • Daily issue file upload    • OCR image analysis                 debits (100% block)     • Sets max $ limit per originator
  • Daily decision cutoff      • Flags washed / altered names     • Best for ZBA/disburse   • Exception review for unlisted

1. Check Positive Pay

Check Positive Pay is an automated fraud detection service provided by cash management banks to protect corporate check disbursement accounts:

• Issue File Transmission: Whenever the corporate treasury or accounts payable system executes a check run, it generates an electronic Issue File containing four critical data fields for each check: Account Number, Check Serial Number, Exact Dollar Amount, and Issue Date. This file is transmitted to the bank via secure SFTP or API.
• Presentment & Matching: When physical checks are presented for payment through the clearing system (Inclearing) or over the counter, the bank's automated clearing engine matches the presented check details against the corporate issue file.
• Exception Handling: Any presented check that does not have an exact match in the issue file (e.g., mismatched dollar amount, unrecognized check number, duplicate serial number, or previously voided check) is flagged as an Exception Item.
• Daily Review & Cutoff Window: The bank posts exception images to the corporate online banking portal each morning (typically by 08:00 or 09:00 AM local time). The treasury team must review the check images and submit a definitive Pay or Return instruction before a strict bank cutoff deadline (e.g., 11:00 AM or 1:00 PM).
• Default Action Rules: Corporations must contractually establish a default instruction if an analyst fails to decision an exception before the cutoff:
  • Default Return (Safest): The bank automatically returns all un-decisioned exception checks unpaid, preventing fraudulent losses.
  • Default Pay (High Risk): The bank automatically pays all un-decisioned exception checks, shifting full legal liability for any resulting fraud directly onto the corporate customer.

2. Payee Positive Pay

Standard Positive Pay matches only the check serial number and dollar amount. If a fraudster intercepts a legitimate $50,000 check payable to "Industrial Supplier Inc." and chemically washes the payee name to "Fraudulent Entity LLC" without altering the $50,000 amount, standard Positive Pay will clear the check.

• Payee Positive Pay Mechanics: The corporate issue file includes the Payee Name alongside the check number and amount.
• Optical Character Recognition (OCR): The bank's imaging systems scan the payee line of presented physical checks using advanced OCR and compare the payee string against the issue file.
• Enhanced Protection: Any mismatch between the printed payee on the check image and the corporate issue file generates an exception, successfully stopping washed and altered payee fraud.

3. Reverse Positive Pay

In Reverse Positive Pay, the corporate customer does not transmit an issue file to the bank. Instead, the bank transmits a daily electronic file of all checks presented for clearing against the customer's account each morning. The company must compare this list against its internal check register and instruct the bank to return any unrecognized items before the daily return deadline.

• Evaluation: Reverse Positive Pay is significantly less secure than standard Positive Pay because it relies entirely on daily manual human intervention under extreme time pressure. If treasury personnel are absent or delayed, fraudulent items clear automatically.

4. ACH Debit Block & ACH Debit Filter

Unlike checks, where funds are drawn via paper, ACH debits allow external originators to pull funds directly from a corporate bank account using only the ABA routing number and account number.

• ACH Debit Block: A blanket rule applied to a specific account that automatically blocks and returns 100% of all incoming ACH debits, regardless of the originator. This tool is ideal for disbursement-only accounts, zero-balance accounts (ZBAs), and payroll accounts that should never experience incoming debit requests.
• ACH Debit Filter (ACH Positive Pay): A customizable filtering tool for operating accounts that must accept legitimate ACH debits (e.g., state tax payments, utility debits, commercial paper maturities):
  • Company ID Whitelist: The corporate client provides the bank with an approved list of 10-digit ACH Company Identification Numbers (Originator IDs) authorized to debit the account.
  • Dollar & Frequency Caps: The corporation establishes maximum single-transaction dollar limits (e.g., State Tax Board Originator ID #1234567890 authorized up to $250,000 per transaction) and allowable transaction frequencies.
  • Exception Adjudication: Any ACH debit originating from an unlisted Company ID or exceeding the specified dollar cap generates an exception alert. The treasury team must review and approve or return the item (as ACH Return Code R29 - Corporate Customer Advises Not Authorized) before the daily NACHA return cutoff.

5. Universal Payment Identification Code (UPIC)

Publishing standard corporate bank account numbers on invoices creates exposure to unauthorized ACH debits and counterfeit check fabrication.

• UPIC Mechanism: Administered by The Clearing House, a Universal Payment Identification Code (UPIC) is a unique, masked 8-to-10-digit alphanumeric account identifier paired with a standard Clearing House routing transit number.
• Credit-Only Functionality: Corporations provide the UPIC to customers and trading partners on billing invoices. The UPIC can only receive incoming electronic ACH credits. It is functionally incapable of processing outgoing ACH debits or check debits.
• Security Benefit: Behind the scenes, the banking system maps the UPIC directly to the corporation's real underlying demand deposit account without ever disclosing the genuine bank account number to the public or external counterparties.

---

Internal Treasury Operational Controls

Bank tools must be supported by strict internal administrative and operational controls within the treasury and finance departments.

Internal Treasury Control Mechanisms:
┌──────────────────────────────┬────────────────────────────────────────────────────────────────────────┐
│ Control Mechanism            │ Operational Requirement & Implementation Rule                         │
├──────────────────────────────┼────────────────────────────────────────────────────────────────────────┤
│ Out-of-Band Callback         │ Mandatory verbal verification for any vendor bank detail change using  │
│                              │ a pre-established telephone number on file (never incoming email info).│
├──────────────────────────────┼────────────────────────────────────────────────────────────────────────┤
│ Maker-Checker Dual Approval  │ Strict segregation: Payment entry (Maker) cannot approve or release    │
│                              │ payment (Checker). System admins cannot initiate or approve.           │
├──────────────────────────────┼────────────────────────────────────────────────────────────────────────┤
│ Hardware Security Tokens     │ Cryptographic TOTP/FIDO2 hardware keys required for payment release.    │
├──────────────────────────────┼────────────────────────────────────────────────────────────────────────┤
│ IP Whitelisting & VPN        │ Bank portal access restricted to corporate static IP subnets.          │
├──────────────────────────────┼────────────────────────────────────────────────────────────────────────┤
│ Daily Prior-Day Recon        │ Automated BAI2 matching of cleared transactions every morning by 10 AM.│
└──────────────────────────────┴────────────────────────────────────────────────────────────────────────┘

1. Mandatory Out-of-Band Callbacks

The out-of-band callback is the single most effective administrative defense against vendor impersonation and BEC bank redirection fraud.

• Definition of Out-of-Band: An authentication method that utilizes a completely separate, independent communication channel from the channel through which the initial request was received.
• The Golden Rule: When an email, letter, or digital invoice arrives requesting a change to a supplier's banking coordinates (routing number, account number, or beneficiary name), under no circumstances should staff use the telephone number, email address, or contact link provided within that correspondence.
• Standard Operating Procedure (SOP):
  1. The analyst retrieves the pre-established, historically verified telephone number for the vendor from the ERP Master Vendor File or the original executed contract.
  2. The analyst places a direct phone call to an established, known corporate contact (such as the vendor's Chief Financial Officer, Controller, or Accounts Receivable Director).
  3. The analyst verbally verifies: (a) that an authentic bank change was requested, (b) the exact new bank routing and account numbers, and (c) the specific pending invoice numbers and dollar amounts.
  4. The callback details (date, time, phone number called, and verified party name) are logged in the ERP audit trail before any vendor master data record is modified.

2. Segregation of Duties (SoD) & Maker-Checker Workflows

Segregation of Duties ensures that no single individual has end-to-end control over any financial transaction:

• Maker-Checker Architecture:
  • Maker (Initiator): Enters payment details (beneficiary, bank account, amount, value date) into the Treasury Management System (TMS) or online banking portal.
  • Checker (Approver): Reviews supporting documentation (purchase orders, approved invoices, contract terms), verifies beneficiary coordinates, and releases the payment.
• Administrative Privilege Isolation: System administrators who configure user permissions and approval matrices must be strictly prohibited from initiating or approving transactions. Conversely, payment makers and checkers must not have administrative rights to alter approval thresholds or user roles.
• Master Vendor File (MVF) Segregation: Accounts payable personnel who create or edit vendor records in the ERP must not have access to enter invoices or initiate disbursements.

3. Technical Authentication & Infrastructure Controls

• Hardware Security Tokens: Replacing static passwords with dynamic Time-based One-Time Password (TOTP) hardware fobs or FIDO2/WebAuthn physical cryptographic keys. A physical token is required at the moment of payment approval and final release.
• IP Whitelisting & Dedicated Banking Workstations: Corporate banking portals and TMS environments are configured to accept connections exclusively from designated corporate static IP addresses or dedicated VPN tunnels. Critical wire releases are often restricted to isolated, hardened workstations that are blocked from general internet browsing and email access.
• Cryptographic File Signatures (PKI): Automated Host-to-Host (H2H) transmission of payment batch files (such as ISO 20022 XML pain.001 or NACHA files) requires digital signatures using Public Key Infrastructure (PKI) certificates and end-to-end encryption (TLS 1.3 or SFTP with SSH keys), ensuring that batch files cannot be intercepted or modified in transit.

---

Comparative Matrix: Bank Fraud Prevention Tools

---

Realistic Treasury Scenario: Positive Pay Exception Decisioning

Consider an operational scenario highlighting daily exception cutoff mechanics:

Incident Timeline

• 07:00 AM: Drawee Bank completes overnight processing and identifies two exception items on Apex Enterprises' disbursement account:
  • Exception 1: Check #8102 presented for $114,500.00. Issue file listed Check #8102 for $14,500.00 (Amount mismatch).
  • Exception 2: Check #8103 presented for $48,000.00 payable to "Apex Capital LLC". Issue file listed Check #8103 payable to "Global Logistics Corp" (Payee mismatch).
• 08:30 AM: Bank posts high-resolution check images to Apex's treasury portal. Bank cutoff is 11:00 AM CST.
• Account Policy: Apex's bank contract specifies Default Return for un-decisioned exceptions.
• Treasury Action:
  • At 10:15 AM, the treasury analyst reviews Exception 1, confirms an amateur alteration adding a leading "1", and enters a Return instruction.
  • At 10:45 AM, the analyst attempts to contact Accounts Payable regarding Exception 2 but gets no response before the 11:00 AM cutoff.

Outcome Evaluation:
• Exception 1: Explicitly returned unpaid before cutoff. Drawee bank returns item through clearing.
• Exception 2: No decision submitted by 11:00 AM. Under the contractual 'Default Return' rule, the
  bank automatically returns the $48,000 check unpaid with return reason 'Positive Pay Exception'.
• Total Loss to Apex Enterprises: $0.00.

Critical Insight: If Apex had established a Default Pay policy instead, Exception 2 would have cleared automatically at 11:00 AM, resulting in a $48,000 fraudulent loss that would be legally unrecoverable under UCC § 4-406 due to the customer's failure to decision the bank's exception alert.