User Guide Data Transmissions - BBVA USA...Ongoing Support Once you have established the connectivity and transmission set up, ongoing product support should be directed to your local

User Guide

Data Transmissions

TM-01-4003B rev. 06/19

Table of Contents

Overview 2

Technical Contact Information 2

Ongoing Support 2

Deadlines 2

Holidays 3

Data Exchange Channels 3

BBVA Net Cash USA 4

BBVA Global Net Cash 5

Direct Channels 5

File Transfer Services 5

BBVA e-Transmit® 7

Account Analysis 8

822 EDI Format 8

Electronic Report Delivery (ERD) 9

Account Reconciliation (ARP) and Positive Pay 10

Positive Pay Issue Files 10

CSV Format (BBVA Net Cash USA) 10

Fixed Width Format (BBVA Net Cash USA) 11

Using SecurePay Software 11

Bank Standard Format 13

BBVA e-Transmit and File Transfer Services 13

ARP Reports 14

ARP Output Files 15

Automated Clearing House (ACH) 17

Direct Channels (BBVA e-Transmit or File Transfer Services) 17

BBVA Net Cash USA 17

Pass-Thru 17


NACHA File Format Origination 18

NACHA File Format - Returns and Notifications of Change (NOC) 33

Same Day ACH Origination 40

Bank Statements (DDA) 41

Balance and Transaction Reporting 42

Formats Available on BBVA Net Cash USA 42

Custom Format or Automated Download 42

BBVA e-Lockbox 43

Payment Exchange Super Format Layout 43

Controlled Disbursement 44

BAI Codes 44

BBVA Net Cash USA Reporting 44

Direct Channels Reporting 44

TM-01-4003B rev. 06/19

Electronic Bill Presentment and Payment (EBPP) 44

Extended Standard A/R File Format Specifications 44

File Layout Definition 45

File Header Record Layout 45

Batch Header Record Layout 45

Payment Detail Record Layout 45

Payment Addenda Record Layout 47

Electronic Data Interchange (EDI) 51


NACHA Format 51

Image Cash Letter (ICL) 52

Integrated Payables 86

Loan Statements 87

Lockbox 89

LRA CD or DVD 89

Image File & Quick Print 89

BBVA Net Cash USA Reporting 89

Accounts Receivable Invoice Matching 89

Custom Format 90

Stop/Accept File Processing Specifications 90

Received ACH Transactions (NACHA Format) 92

Sweep Statements 93

Wire Transfer Reporting 94

Glossary 100

2

OverviewThank you for choosing BBVA for your Treasury Management services. This guide is not intended to replace product specific user guides, such as the ACH or ARP and positive pay services user guides. It is assumed that this guide will be used by technical specialists who need to know formats and specifications to create files and/or establish connectivity to download data and images.

Technical Contact Information

Voice Email

BBVA Net Cash USA 1- 866-488-1858 toll-free [email protected]

ARP and Positive Pay 1-800-239-1100 ext 6869 [email protected]

ACH 1-800-239-1100 ext 1268 [email protected]

Ongoing Support

Once you have established the connectivity and transmission set up, ongoing product support should be directed to your local Business Relationship Services area.

Voice Fax Email

Business Relationship Services

Alabama and Florida 1-800-607-4444 205-297-6140 [email protected]

Arizona, California, Colorado, New Mexico and El Paso, TX 1-800-236-2059 1-866-710-5186 [email protected]

South Texas, except El Paso 1-800-570-2791 1-713-993-8551 STexasBRSClientServices.us@BBVAcom

North Texas 1-866-876-4922 1-877-527-9736 [email protected]

Deadlines

All ACH files must be received by BBVA no later than 6:00 p.m. CT at least 1 business day prior to settlement (payment) date. However, to help ensure timely posting by receiving banks, we highly recommend that consumer credit files (e.g. direct deposit files) be submitted to us 2 business days prior to settlement date. We pass ACH files to the Federal Reserve twice during each business day at 11:00 a.m. CT and 6:00 p.m. CT. These times are followed without exception. BBVA cannot “hold” a window open in order to receive your file. For interbank same day ACH please see the “Same Day ACH Origination” on page 39.

All positive pay issue files must be received by 10:00 p.m. CT to be posted the same business day. Files received between 10:01 p.m. to midnight will be posted the next business day. Process actually starts at 10:30 p.m. CT.

Balance and transaction information reporting files are available by 7:00 a.m. CT each business day.

Refer to the controlled disbursement section for availability of files based on disbursement site.

Account Analysis Statements are available no later than the 15th calendar day of each month, unless you are on a quarterly or non-standard cutoff.

Lockbox file availability depends on the cutoff established during service implementation. ARP output files are available no later than the 5th business day after statement cutoff for partial/paid reconciliation and the 7th business day after statement cutoff for full reconciliation.

3

Holidays

BBVA observes all Federal Reserve holidays.

Listed below are some important things to keep in mind when establishing an effective date for your ACH files:

• Files should not have an effective date that falls on a Federal Reserve holiday. Should you create an ACH file with an effective date on a Federal Reserve holiday, the settlement date will be changed to the next business day.

• Files should not be submitted with an effective date that is the same day the file was transmitted.

• We can receive your files on federal holidays, but ACH files will not be forwarded to the Federal Reserve Bank for processing until the next business day.

• If you require the ACH transactions to settle the day prior to the Federal Reserve holiday, be sure to add an additional day to the file transmission schedule. This will ensure that the receiver of the funds has use of them during the holiday.

BBVA is open the business day before and the day after the Thanksgiving and Christmas holidays. Positive pay exceptions are reported on these days. If your office will be closed on these days, consider updating your default disposition online. Decisions are due by 6:00 p.m. CT the next business day after posting. Exceptions are also reported on the mobile app. If no one responds to the positive pay exception notification, we will follow the default instructions on file (in most cases the default instructions is to return the check unpaid).

Data Exchange ChannelsWe have two main channels for customers to send and receive treasury management reports and files to/from BBVA. The two channels are: BBVA Net Cash USA and the Direct Channels transmission product family (File Transfer Services or BBVA e-Transmit).

Tip: The type and format of the file are the main drivers on which transmission channel will be used. Refer to the individual sections on each type of file or report for more details.

Direct ChannelsFile or Report File Transfer Services BBVA e-Transmit BBVA Net Cash USA

ACH files and transactions NACHA format NACHA format NACHA format manual input, batch/file input, or Pass

thru files; Also export in NACHA and CSV formats

ACH return and notification

of change

NACHA format NACHA format Electronic Report Delivery (ERD) text format

Account analysis 822 format 822 format Electronic Report Delivery (ERD) text format

Account reconciliation (ARP)

and positive pay

Custom format or

standard Fixed Width

format or CSV

Custom format or

standard Fixed Width

format or CSV

Issue file: comma-delimited (CSV) fixed width/text

(TXT) Output file report: custom or standard format

Balance and transaction

reporting

Custom format

BBVA standard Fixed

Width format

Custom format

BBVA standard Fixed

Width format

BAI format, comma-delimited (CSV), CS Basic, PDF,

MT940/942, Webconnect (OFX) to Quicken and

Quickbooks

Bank (DDA) statement eStatements PDF

Format

Not available Electronic Report Delivery ( ERD) text format or

eStatements in PDF Format

Controlled disbursement Custom format

BAI format

Custom format

BAI format

BAI format, comma-delimeted (CSV), CS Basic, PDF,

MT942

EDI Transactions NACHA format NACHA format Electronic Report Delivery (ERD) Text format

Intra-day wire

transfer reporting

BAI format Not available BAI format, comma-delimited (CSV), CS Basic, PDF,

MT942

Loan statements Not available Not available Electronic Report Delivery (ERD) text format

4

Direct ChannelsFile or Report File Transfer Services BBVA e-Transmit BBVA Net Cash USA

Loan balances

and transactions

Not available Not available Comma-delimited (CSV), PDF format

Lockbox deposits Image File Custom format (text

only)

Comma-Delimited (CSV)

Received ACH NACHA format Not available Not available

Sweeps statements Not available Not available Electronic Report Delivery (ERD) text format

BBVA Net Cash USABBVA Net Cash USA is the online and mobile cash management portal for BBVA where customers can:

• Obtain current/same and previous day information (transaction) reporting

• Place stop payments as well as initiate account transfers and loan transfers

• Perform positive pay activities and submit business decisions to drive future transaction processing

• View at a glance RealTime Account Reconciliation status, query customized reports, and access numerous standard output files and reports

• Create/send ACH files and transactions

• Obtain images of paper credits and debits

• Obtain enhanced lockbox reporting

• Use wire transfer services

• View reports using the Electronic Report Delivery (ERD) module

Importing Exporting

• ACH batches/files

• ACH Pass-through files

• Positive pay/ARP Issue files

• Wire transfers

• Account transfers

• Balance reporting (Wires, ACH, controlled disbursement, debits, credit, lockbox, etc.)

• Lockbox deposits and remittance information

• Account reconciliation reports and output files

• Loan balances and transactions

• Bank statements in PDF format

Electronic Report Services

• Account analysis

• ACH return items and Notifications of Change

• Bank statement

• EDI report

• Commercial loan statement

• Shareholder (Goldman Sachs Mutual Funds) statement

• Safekeeping reports

The Electronic report service allows customers to view an electronic version of paper/text reports. The reports may be viewed online or printed, but not downloaded in data format. For example, if you want to see your ACH Returns reports, you can view it online or through the mobile app and it will look like the paper reports normally sent by regular or overnight mail. But this information is not in a format that can be exported to an accounting or ERP (enterprise resource planning) system. Refer to the individual product sections in this guide for details on other options if needed.

5

BBVA Global Net Cash• Obtain visibility into full, global cash position. Access all account balances and transactions worldwide,

whether they are held at BBVA or another bank.

• Customer must already have a Global net cash customer ID with an account in BBVA Spain, Portugal, UK, Belgium, France, Mexico, Colombia, Peru, Venezuela, Argentina, Hong Kong, or New York.

• BBVA and other third party bank account and transmissions sent via MT940. MT940s report account balances and transactions on a previous day basis.

Direct ChannelsThe term Direct Channels refers to the group of transmission methods outside of the BBVA Net Cash USA platform. There are 2 types: File Transfer Services and BBVA e-Transmit.

Tip: All Direct Channels transmission types provide customers with confirmation reports showing files have been picked up or sent. File testing is mandatory for all new customers and file transmissions.

File Transfer Services

File Transfer Services is a web-based file transmission platform that allows customers to send and receive files related to product offerings such as:

ACH services including ARP services including

• Origination files

• Return files

• Received ACH

• Positive Pay check issue files

• Issue files

• Output Files

Card Services Including CDA services including

• Card Recon file

• Suspend Card file

• Summary Report individual (or consolidated) file

• Detail Report individual (or consolidated) file

• Summary and Detail Report individual (or consolidated) file

Lockbox services including ICL services including

• Transmission Files

• Stop Files

• Image transmission files

• Remittance archive (LRA)

• Image Cash Letter Files

Information Reporting services including

• Analysis Statement

• DeposiTrack statement

• BAI Wire Reporting file

• EDI Info Reporting statement

• eStatements in PDF format

6

System Administrator

When deciding who should serve as the system administrator, please note that this individual will be the single point of contact with BBVA regarding the establishment of communication protocols. The system administrator will be the only person to receive critical information from BBVA regarding passwords and certificates for your connection. The system administrator will also be responsible for sending BBVA any applicable information and files (keys, certificates, user IDs, passwords, etc) related to the communication protocol chosen. These will be sent to: [email protected]

Note: Because of the highly sensitive nature of this communication, BBVA must be notified immediately if the email address we have on file as your system administrator changes or is no longer valid.

Communication Protocols

SFTP

We support Secure FTP encryption with SSH key for file transmissions sent to and from BBVA. Requirements include:

• TCP/IP network interface

• Pre-defined port 10022

• FTP client software supporting the SSH standard, with a maximum SSH key length of 2048 characters

• [optional] PGP file encryption

• This option will require the bank to send you our public key

• optional] File compression usingZIP and other mutually agreed upon compression utilities

• Only 1 file per ZIP

• Multi-factor authentication by using a combination of username/password and a public key which must be provided to BBVA (a private key exists on your side). The use of optional PGP file encryption can also satisfy multi-factor authentication requirements instead of using an SSH key.

FTPS

FTP/SSL requires the exchange of SSL (secure socket layer) certificates with BBVA. Requirements include:

• TCP/IP network interface

• FTP software supporting RFC2228 standard for FTP over an SSL session (SSL cert)

• Pre-defined port 10031

• [optional] PGP file encryption

• This option will require the bank to send you our public key

• [optional] File compression using ZIP and other mutually agreed upon compression utilities

• Only 1 file per ZIP

• Multi-factor authentication by using a combination of username/password and public authentication certificates which will need to be provided to BBVA. The use of optional PGP file encryption can also satisfy multi-factor authentication requirements instead of using an SSL certificate.

• SSL certificates sent to you by BBVA will be SHA-256 with RSA

Staging and Production

The Sterling Integrator platform that File Transfer Services uses allows for a staging environment where testing can occur. Once you are satisfied with the level of pre-production testing performed in the staging environment, you will then be given access to the production environment. The URL associated with each environment is shown below.

Staging: stage-gateway.bbvausa.com

Production: gateway.bbvausa.com

7

Mailbox Directory Structure

When you log into the File Transfer Service system, the directories available are determined by the user account you are using. Only the services you have signed up for will be available. It should also be noted that you can further limit the directories available for each user account associated with your contract.

Note: The actual directory names are pending.

Directory Treasury Management Service Comments

\3085\I1 ACH – inbound to bank Up to 9 directories, depending on your ACH set up

\3085\O1 ACH – outbound to customer Up to 9 directories, depending on your ACH set up

\3080\I1 ARP/Positive Pay – inbound to bank Up to 9 directories, depending on your ARP set up

\3080\O1 ARP – outbound to customer Up to 9 directories, depending on your ARP set up

\3090\O1 Account Analysis (822) Analysis statement will be delivered here

\3094\O1 BAI Information Reporting BAI information report will be delivered here

\3093\O1 Controlled Disbursements CDA report will be delivered here

\3091\O1 DeposiTrack DeposiTrack statement will be delivered here

\3092\O1 EDI Reporting EDI report will be delivered here

\3095\I1 Image Cash Letters Up to 9 directories, depending on your ICL set up

\3075\O1 Lockbox – outbound to customer Up to 9 directories, depending on your Lockbox set up

\3075\I1 Lockbox – inbound to bank If applicable, depending on your Lockbox set up

\3040\O1 PDF Bank Statements O1 for monthly and O2 for weekly

\3096\I1 Spend Net Payables Suspend card file

\3096\O1 Spend Net Payables Reconciliation file will be delivered here

\3090\I1 Account Analysis (822) Analysis statements from outside the bank

Note: ACH and ARP verification reports will be delivered to the corresponding outbound directory; for example, if your ACH set up calls for the creation of 3085\I1 and 3085\I2 directories, then the verification report will be dropped off in the corresponding outbound directory; 3085\O1 for files dropped in 3085/I1 and 3085/O2 for files dropped in 3085/I2.

BBVA e-Transmit

BBVA e-Transmit is an HTTPS based transmission protocol. It does require “multi-factor authentication” in that a customer must login twice to be able to access it.

This transmission method does NOT allow customers to use automated scripts to send their files. Customers must login and manually upload or download the files. If you want to use an automated script, you will need to send files using File Transfer Services.

Exception to this rule: There are 2 vendors who have created automated scripts on their software using screen scraping programs of the BBVA e-Transmit site. If you use AP Technology’s SecurePay software or Reynolds and Reynolds to send your positive pay issue files, they may have a feature embedded within their software to ‘automate’ the transmission of files using the BBVA e-Transmit platform.

8

BBVA e-Transmit is compatible with both internet Explorer and Netscape. It has not been tested with other web browsers such as Mozilla or Firefox.

Account AnalysisBBVA can provide account analysis statements in three formats: paper, electronic report delivery (ERD), or file transmission (822 EDI format).

822 EDI FormatElectronic Data Interchange (EDI) is a traditional form of electronic commerce that uses structured electronic transactions within established standards to exchange data between two companies. There are hundreds of transaction sets with specific formats. Account analysis transaction set (822) is used to transmit detailed balance, service charge, and adjustment detail primarily from a bank to its corporate customers. It uses the ANSI ASC X12 (4010) format.

Refer to the publication from the Association of Financial Professionals titled “AFP Guide to Account Analysis: Statement Standards and Transaction Set 822 Implementation Guide” for detailed instructions on the EDI account analysis format and a translation of the codes used.

9

Electronic Report Delivery (ERD)Customers can receive an electronic version of paper reports using the BBVA Net Cash USA Electronic Report Services. The reports may be viewed online or printed, but not downloaded in data format. Shown below is an example of an account analysis statement presented online or through the mobile app.

10

Account Reconciliation (ARP) and Positive PayThere are multiple methods for transmitting ARP and positive pay issue files to BBVA and for receiving ARP output files. The file format you want to use will determine which transmission channel will be needed.

Positive Pay Issue FilesPositive pay issue files have the following mandatory fields: account number, check serial number, dollar amount, check issue date, and issue/void/cancel indicator. Files sent using the bank standard format also require the bank number. The payee information field is optional.*

CSV Format (BBVA Net Cash USA)

Several accounting applications, most notably Microsoft® Excel, can convert files to a comma delimited (CSV) format. CSV files may be uploaded to BBVA Net Cash only; it cannot be sent through any other transmission channel. You will not need to upload a test file to BBVA Net Cash. If the file is in the wrong format, the upload will fail. You should always check issue file status after uploading a file to ensure that the file was successfully uploaded.

You can reorder the fields, but your file must contain the fields below. In order to use this format, the fields in your file must be separated with a comma (,) to indicate the beginning of a new field.

Input Specifications

Field Name Field Length

Field Type Required or Optional

Comments

Account 10 Numeric Required As assigned by BBVAC. Sample: 0000777777

Check number 15 Numeric Required Right justified, zero fill

Sample: Check 456789 expressed as 000000000456789

Dollar amount 15 Numeric Required Amounts are explicit decimals without commas, right justified,

zero fill.

Sample: $9,999,999.00 should be 000009999999.00

Issue date Varies Numeric Required You must select from one of the following options:

mmddyy

mmddyyyy

mm/dd/yy

mm/dd/yyyy

YYYYMMDD

m = month; d = day; y = year

Issue / void indicator 1 Alphanumeric Required Issue=I, Void=V

Payee information 70 Alphanumeric Optional* Name of payee on check as listed by company on their check

issue file.

Sample: Charles Philip Arthur George Mountbatten-Windsor

* If you subscribe to Payee Positive Pay, where the bank verifies the name of the payee on the check presented for payment against the issue file, you are required to include the payee name in your issue file.

11

Fixed Width Format (BBVA Net Cash USA)

Some accounting applications use a fixed format rather than CSV. If you can create a fixed width file in the exact format listed below, the file can be uploaded to BBVA Net Cash. You will not need to upload a test file to BBVA Net Cash. If the file is in the wrong format, the upload will fail. You should always check issue file status after uploading a file to ensure that the file was successfully uploaded.

File Names: You can use whatever you wish for the file name, but the expected maximum length of the file name is 20

characters. Files with longer names will be processed with the filename truncated.

Zero Fill: It is assumed that your file will contain leading zeroes in each field. If it does not contain leading zeroes, be

sure to setup the “trim zeroes” option in your issue file template on net cash.

Fixed Record (TXT) Format: You can determine the starting and ending positions of each field as well as the field length, but your file must have the minimum information below.

Input Specifications

Field Name Field Length

Field Type Required or Optional

Comments

Account 10 Numeric Required As assigned by BBVAC. Sample: 0000777777

Check number 4 Numeric Required Various check processing equipment in the industry require

checks to have a minimum of 4 and maximum of 13 digits

Dollar amount 10 Numeric Required Amounts are explicit decimals.

Sample: $9,999,999.00 should be 9999999.00

Do not include the dollar sign.

Issue date 6 Numeric Required You must select from one of the following options:

mmddyy

mmddyyyy

mm/dd/yy

mm/dd/yyyy

YYYYMMDD

m = month; d = day; y = year

Issue / void indicator 1 Alphanumeric Required Issue=I, Void=V

Payee information 10 Alphanumeric Optional* Name of payee on check as listed by company on their check

issue file. Maximum field length: 70 characters

Sample: Charles Philip Arthur George Mountbatten-Windsor

* If you subscribe to Payee Positive Pay, where the bank verifies the name of the payee on the check presented for payment against the

issue file, you are required to include the payee name in your issue file.

Using SecurePay Software

AP Technology has a software package called SecurePay that can work with most accounting packages to convert your list of issued checks to the BBVA format and transmit it in unattended/automated mode. The software includes a 1 year maintenance agreement.

Tip: SecurePay files must be transmitted using BBVA e-Transmit or File Transfer Services. These files can not be uploaded into BBVA Net Cash USA.

12

SecurePay is compatible with almost ANY accounting application data file. Following is a partial list of compatible accounting applications:

A Accuity Enterprise Suite

ACT 1

Activant

Adams

ADEPT

Adnet

ADP

ADP 5800

ADP 9200

ADP 9400 UNIX

ADP AC975

ADP Encoda Systems

ADP Payroll

Advance America

Advantage

AFD

Affinity Quadramed

AFS Food Distribute

AFW

Agricultural Data

Agris

AHIS

AIM

AIM for Windows

AKA Park Chevrolet

American Fundware

American Fundware AP

AMSI

Amtech

Antrim

Aptron Campus Package

Aremis Soft Fourth Swift 7

Aremisoft Fourth Shift

Armour Systems

AST Placement

ASW

Automated Office Systems

Axium

B Baan

Baan ERP

Baan MPEC

Baan UNIX

Best Enterprise Suite

Bidtek Viewpoint

BiTech

BiTech CK200

BizPack

Blackbaud

Blackbaud AP

Blackhard Accounting

BLOCS

Blue Ridge Software

Borland Report Smith

Bottomline Technologies

Bottomline Technologies

Create!form

BST

BUCS

Business Systems

Business Works Gold

C Cadillac Sales Company

California Software Baby

36

CBS Client Book

CDCI BUCS

Business Systems

Business Works Gold

Cadillac Sales Company

California Software Baby

36

CBS Client Book

CDCI

Cedar Enterprise

Solutions

Centauri

Ceridian

CHAS

Cheetah

Chilson’s

Civica CMI

Clarus

CMHC

COATS

Cobalt

Collection Data Collect

Collier Jackson

Columbia Ventures

Comet Signature Systems

Commerce Center

CompuPay

CompuPower

Compusource UGI

Computer Concepts

Computer Guidance

Computron

Connected Accounting

Construction Partner

Creative Solutions

CSC RiskMaster

CSD

CSI

CSS

Custom Homebuilders Solution

Cutsey FDM4

CWS

Cyborg Coda

CYMA

CYMEX

D Data Basics

Data National

Dataforce Spectrum

DataLine

Datamodes AgraSoft

DataPlus

DataPro

Datatel

Dataworks

Delcambre

Deltek Cospoint

Deltek GTS Premier

Deltex Advantage

DMAS

DMS

Doane System 4

Dynamics

Dynamics AX

Dynamics Enterprise

E e-ASG

EBS eClibsystems SPFM

Eclipse

ECS

EDS DMS

EDSI

Electronic Bank Window

Elite Information Systems

EMS TLM

Encode Envision

EPES

Epicor

Epicor Advantage 6.1

Epicor eBackOffice

Epicor Platinum

ERP

Escape

Everest

Exact Macola

Exact Macola Progresssion

Executive Data Systems

Expandible

Explorer

EZ Cap System

F F shift

Factor

Facts UNIX

Falcon

Famous

Famous Software

Fastrak

FDM4 UNIX

Festival Fun Park

Finance Master

Financial Edge

FMS FOCUS

Folcrum

ForeFront

Fourth Shift

FoxPro Holm-Dietz

H Horizon HPVectra HRMS Hunter Douglas

I IBAX Series 2000

IBM Infindinet

IBM Mapics

IDS

IDX

IFIS

IFS TriMin Systems

IGT

IIPS

Impac

IMS

Infiniti Net

Infinium

Infinium AP

Infinium PR

Infomaker

Infomax

InnoPrise

InterSoft

Intuit QuickBooks

Intuit Quickbooks Enterprise

Intuit Quickbooks Premier 2004

Intuit QuickBooks Professional

Intuit Quicken

Intuit Quicken 2000

Intuit Quiken Deluxe 2004

IPS Sendero

J Jamus

Javelan

JBA

JBA Corporation

JD Edwards

JD Edwards One World

Jenzabar

Jenzabar - EX

Jenzabar - PX

Jenzabar - TE

K Kayenta

KCSI

Key Point DM

Keystone

King Management

Kintera Fundware

KVS

L Lawson

Lawson Insight

Lawson Paychex

LGDPC Flexgen

Libra

LightSpeed

LightSpeed NXT

Lilly Visual Manufacturing

Lincoln Data

Lions Gate

Loss Run M1

M MACC - Accounting

Master

Made to Manage

Manman

Mantissa

Mapics

Masterbuilder

Masterpiece

Maxwell Systems

Maypix

Maypix Nova

MCBA

MCCC IFS

McCullah

McKesson Mediclick

MCP

MCS

Meditech Magic

Megasis Financial

Accounting

MetalPro

Methods Progress

Metrotempak

MFG Pro

MFG Pro QAD

Microsoft Dynamics AX (formerly

Microsoft Axapta)

Microsoft Dynamics GP (formerly

Microsoft

Great Plains)

Microsoft Dynamics NAV

(formerly Microsoft Navision)

Microsoft Dynamics SL (formerly

Microsoft Solomon)

Microsoft Excel

Microsoft Great Plains

Microsoft Great Plains Dynamics

Microsoft Great Plains

eEnterprise

Microsoft Great Plains Purchasing

Microsoft Great Plains Realworld

Microsoft Navision

Microsoft Small Business

Manager

Microsoft Solomon

Microsoft Solomon

Medical

Manager

Microsoft Solomon IV Backoffice

MICS

Miller-Nicholson

MIP Mobius

Movix

MS Access

MTA

Multiple

MUNIS

N NSG NxTrend NxTrend SX Enterprise

O Omnicom

Open 4

Open Accounts

Open System

Optimum Solutions

Oracle Financials

Oracle Horizon

Oracle Payables

Oracle Paybase

Order Power

Orion

OSAS

13

P P2 Energy Solutions

Paybase

PayPlus

PayPlus Software

Payroll Director

PC Accting Software Inc

PDS

PDS

Peachtree Accounting

2000 by Sage

Peachtree by Sage

Peachtree Complete by

Sage

Peninsula Software

Pensoft Payroll

Penta

PeopleSoft

Perfect Practice

Petrocomp

PICK

Platinum

Poise

Praxa

Precision 2000

Prelude

Prime Pay

Prism

Pro Logic - UNIX

Pro-Bate Plus 4

ProBusiness

Produce Pro - UNIX

Profit 21

ProForms

Protrust

ProVantage

Q QAD QAD - UNIX Quantel Quantra Services

R RandR

RandR ERA

RB Associates

RB Associates Management Co.

Real Page Real World Senior

Systems

RealWorld

RedRiver Businessware Software

RedWing

Reflections

Retail Interact

Reynold and Reynold

ROI Systems Manage 2000

Ross

Ross Financials

RTI

S S2K

Sage ABRA

Sage AccPac

Sage Business Works

Sage Carpe Diem

Sage MAS 200

Sage MAS 500 Sage MAS 90

Sage PR Companion

Sage Software

Sage Timberline

Sage Timberline Accounting

Sage Timberline Gold

Standard

SamPro

SAP

SAP Small Business SBT

SBT Fox

SBT Vision

Scorpio

SCT Banner

Semaphore

Shaker Coins

Shamrock Systems Manke

Shelby Siemen Invision

Silent Partner

Siteline

Skyline American Contractor

SmartStream

SMS

SoftPro Corp

Software House International

Software Solutions

Southeastern Data

SPT

SQL Financials

SSA

SSA Infinium

SSI

Star Builder

State of the Art

StelPlan

StoftPro STS

StudioII Studio Designer

Sungard Pentamation

SunGuard Investor Accounting

Support Net

Swift

Symax Symbion Physicans

Services

Symex

Systems Union

Syteline

T TAM

Team Financial

Tech Systems

Technalysis

Technical Systems

Thomson Elite

Thoroughbred

TIES TKO Systems

Total HR

Triad CSD

Triple Tech

Tripletek Software

Trizetto

Trust Accounting Package TSC

Turniels

TurnKey

U UCS

UDS

Ultima Software

ULTIPRO

Uniplex

Universal Computer System

V Vantage

Varipro

VCG Staff Suite

VCG Tempware

Vega Products

VersiData

Versyss Lumberyard

Vertical Market Systems

VIP

Visibility Visual Account Mate

Visual Manufacturing

W Wind 2 WindMan WLT

X XYTECH Systems Enterprise

Y Yard1 Yardi Systems Enterprise YesICan Y-Vision

Z Zenith Administrators ZiTech

Bank Standard Format

BBVA e-Transmit and File Transfer ServicesBBVA also has a bank standard that you can use to send your positive pay issue files. If you use this method, you will need to be set up for one of the Direct Channels transmission methods (File Transfer Services or BBVA e-Transmit).

File Format: All issue (input) files sent through these transmission channels must be in a fixed record (also known as

TXT) format. A sample layout is shown below.

Multiple Accounts: A file can contain multiple accounts. The standard format does not include a header or trailer record. If

you plan to use a non-standard format, you need to have only 1 header record, regardless of the number of

accounts within the file.

File Names: You can use whatever you wish for the file name, but the expected maximum length of the file name is 20

characters. Files with longer names will be processed with the filename truncated.

Zero Fill: You are required to use leading zeroes in each field.

Header and Trailer Records:

Header and trailer records are not used in the BBVA standard format but may be added to a custom format

if desired. If used in your custom format, please ensure that your Header and Trailer records do not begin

with “H” or “T”, as this will cause processing errors.

Standard Format for Files Sent via BBVA e-Transmit or File Transfer Services

Field Name Starting Position

Ending Position

Field Length

Field Type Comments

Account 1 10 10 Numeric Zero fill to the left if the account has less than 10 digits

14

Standard Format for Files Sent via BBVA e-Transmit or File Transfer Services

Field Name Starting Position

Ending Position

Field Length

Field Type Comments

Check number 11 25 15 Numeric Zero fill to the left if the check has less than 15 digits

Dollar amount 26 40 15 Numeric Do not include the decimal nor the dollar sign. Zero fill to

the left if the amount is less than 15 digits.

Sample: $9,999,999.00 should be 000000999999900

Issue date 41 48 8 Numeric MMDDYYYY where m = month; d = day; y = year

December 31, 2018 expressed as 12312018

Issue / void indicator 49 49 1 Alphanumeric Issue=I, Void=V

Payee information 50 119 70 Alphanumeric Left justify payee name and space/blank fill on the right

Name of payee on check as listed by company on their

check issue file. Maximum field length: 70 characters

Sample: Charles Philip Arthur George Mountbatten-

Windsor

Sample Issue File in Standard Format

012345678900000000456889200000099999990012312018ICAPTAIN HORATION MAGELLAN CRUNCH

012345678900000000456889300000000009990012312018IALOYSIUS SNUFFLEUPAGUS

012345678900000000456889400000143227090012312018IPEPPERMINT PATRICIA REICHARDT

012345678900000000456889500000000001990012312018IOSCAR ZOROASTR AMBROISE DIGGS

012345678900000000456889600000000002849912312018IBULL NOSTRADAMUS SHANNON

012345678900000000456889700000113249573312312018VMILBURN PENNYBAGS

012345678900000000456889800000000001000012312018ISHAGGY NORVILLE ROGERS

ARP ReportsAccount Reconciliation (ARP) reports are delivered in PDF format through BBVA Net Cash USA. Reports may be downloaded from the Account Reconciliation Reports screen within the Risk and Reconciliation module of net cash. Each report is in its own PDF file and the reports returned to you from the search will vary depending on the service you have setup. For a full list of tall the available reports by service type and samples of each report, ask your treasury management officer (TMO) for the ARP Report Samples document.

Account SummaryAdjustment Transactions Outstanding Settlement RecapPosted Transactions Recap Deposit location (LOC) option High Order Prefix (HOP) option Merchant (MER) option

Transaction DetailCleared paymentCredits postedDebits postedOutstanding checksStale dated itemsVoid/Cancelled payments

Cleared payments – HOP optionOutstanding checks – HOP optionStale dated items – HOP option Void/Cancelled payments– HOP option

Deposits Deposit reconciliation by locationDeposit reconciliation by merchantDeposit reconciliation detail

15

ARP Output FilesThe file specifications listed represent the preferred BBVA standard layout in a comma separated values (CSV) format. A fixed width (TXT) file is possible but it is considered a non-standard output file format.

File Delivery and Accounts:

Files may be delivered via the ARP Dashboard on BBVA Net Cash USA, BBVA e-Transmit or File Transfer

Services. It is possible for the same file(s) to be delivered to multiple channels. A file can contain multiple

accounts.

Header and Trailer Records:

The BBVA standard format does not include a header nor a trailer record. It only contains detail records.

Header and Trailer Records may be added to custom file formats.

Standard BBVA ARP Output File Format Layout

Position Field Name Field Length

Field Type Format Comments

1 Account Number 10 Numeric Right justified

Zero filled to

the left

This will be the account number which can be up to 10

digits.

2 Item Status 1 Alphanumeric Text Possible Values:

C = Paid Checks

P = Presented Transactions (ACH and Wire transactions

are reported in this category)

M = Paid Checks Match

D = Deposits File

I = Outstanding Issues

V = Voids Matched

U = Voids Unmatched

3 Debit / Credit

Indicator

1 Alphanumeric Text Possible Values:

C = Credit

D = Debit

I = Outstanding Issue or Void Matched

V = Void Unmatched

4 Issue Date 10 Date YYYY-MM-DD Date the check was issued. Sample: September 17, 2018

will be 2018-09-17. If the transaction is not a check or

there is no issue data, this field will be blank.

5 Issue Amount 15 Numeric Right justified

No decimal

(implied)

Zero filled to

the left

The amount of the check was written for, sample: 28000

will be sent for a check written/issued in the amount of

$280.00. If no issue data, this may be all zeroes.

6 Issue Serial

Number

15 Numeric Right justified

Zero filled to

the left

Number of the check. Sample: 000000000110795. If no

issue data, this may be all zeroes.

7 Issue Payee Name 70 Alphanumeric Text with

commas

removed

Payee name on check in the payment (issue) file. This is

the name that should be printed on the check as it was

mailed to the payee. If the transaction is not a check or

there is no issue data, this field will be blank. This is not

a fixed length field and it is not padded with spaces. The

field length specified is the maximum length.

8 Paid Date 10 Date YYYY-MM-DD Date the transaction paid on the account. Sample:

September 17, 2018 will be 2018-09-17

9 Paid Amount 15 Numeric Right justified

No decimal

(implied)

Zero filled to

the left

The amount of the paid transaction. Sample: 28000 will

be sent for a check paid in the amount of $280.00

16




10 Paid Serial

Number

15 Numeric Right justified

Zero filled to

the left

Number of the check. Sample: check 102606 will be

shown as 000000000102606

11 Tran Code

Description

30 Alphanumeric Text field that

is not padded

with spaces.

Field length

represents

the maximum

length of

characters.

ACH CREDIT

ACH DEBIT

ACH IN-HOUSE CREDIT

ACH IN-HOUSE DEBIT

ADJUSTMENT CREDIT

ADJUSTMENT DEBIT

BRANCH DEPOSIT

CASHED DEBIT

CHECK CLEARED

CREDIT MEMO

CREDIT REVERSAL

DEBIT FORCE PAY CHECK

DEBIT MEMO

DEBIT REVERSAL

DEPOSIT

DEPOSIT CORRECTION CREDIT

DEPOSIT CORRECTION DEBIT

FED CLEARING DEBIT

FORCE CHECK

FORCE PAY CREDIT

FORCE PAY DEBIT

INCOMING WIRE

INITIAL DEPOSIT

INTL WIRE TRANSFER

EBANKING BOOK TRSF CR

EBANKING CASH BOOK TRSF DB

LOCKBOX DEPOSIT

MOBILE DEPOSIT

OUT INTL WIRE FX

OUT WT E-ACCESS

OUT WT EBANKING

OUT WT EBANKING INT USD

OUTGOING WIRE

OUTGOING INTL WIRE FX

OUTGOING INTL WIRE USD

REGULAR CHECK

TELLER CASHED DEBIT

12 ACH Company ID 10 Alphanumeric Text 10-digit Identifier associated with trading partner. This

number is typically assigned by the sending bank.

For example, a company ID for XYZ Company may be

1066033492

13 ACH Company

Name

40 Alphanumeric Text with

commas

removed

Name listed in the ACH Company Name field as the

transaction was processed - this is how it was submitted

by the sending bank. Sample: XYZ Company

14 ACH Description 30 Alphanumeric Text with

commas

removed

Description of transaction as entered by sending bank.

17




15 Wire Fed

Reference Number

35 Alphanumeric Alphanumeric Tracking number assigned by Federal Reserve Bank to

external wire transactions.

16 Wire Bank

Reference Number

16 Alphanumeric Alphanumeric Tracking number assigned by BBVA to wire transactions.

17 Wire Sending Bank

Number

9 Alphanumeric Alphanumeric Number to identify sending bank, this is typically

assigned by Federal Reserve.

18 Wire Beneficiary

Bank Number

9 Alphanumeric Alphanumeric Number of the wire recipient’s bank, as listed on the

transaction.

19 Wire Beneficiary

Name


commas

removed

Name of the wire recipient (payee), as listed on the

transaction.

20 Wire Originating

Party


commas

removed

Name of the company that sent the wire payment, as

listed on the transaction.

Automated Clearing House (ACH)

Direct Channels (BBVA e-Transmit or File Transfer Services)Once you are ready to transmit a test file, contact our specialists listed in the technical contacts section. The specialist will work with you to test connectivity and to accept your first test file. This test file is not processed in our ACH system. It is simply used to verify that your ACH file is in the proper NACHA format. If there are any formatting problems with your file, our NACHA file specialist will contact you. Once you receive confirmation that your ACH file format is correct, you will be ready to go live with ACH services.

Tip: BBVA can only verify the format of your ACH file and not the information contained within the file. Therefore, we highly recommend you create a prenotification file for recurring ACH transactions to help ensure that the information contained within the file is accurate. Please refer to the prenotification entries section for more information.

BBVA Net Cash USAYou (or the designated Corporate Administrator in your company) should have received a BBVA Net Cash welcome package. The resources in this packet provide you with set up procedures and the process for establishing ACH templates.

Pass-Thru

If you are creating your own NACHA formatted file and plan to use BBVA Net Cash to transmit the file to us using the pass-thru function, instructions for doing so are included in the online help. The pass-thru function will inform you of any formatting errors you need to correct.

Tip: BBVA can only verify the format of your ACH file and not the information contained within the file. Therefore, we highly recommend you create a prenotification file for recurring ACH transactions to help ensure that the information contained within the file is accurate. Please refer to the prenotification entries section for more information.

18

Electronic Report Delivery (ERD)Customers can receive an electronic version of paper reports using the BBVA Net Cash Electronic Reports Services. The reports may be viewed online or printed, but not downloaded in data format. Shown below is an example of an ACH return notification presented online or through the mobile app.

NACHA File Format OriginationIMPORTANT NOTE: The formats outlined in this document were established by the National Automated Clearing House Association (NACHA) and are subject to change. Please consult the most current edition of the ACH rules published by NACHA to ensure you are using the most up to date NACHA file format.

General InformationField: A field is a group of characters or numbers that represent one piece of information. For example, Field 6 in the File Header Record contains the time your ACH file was created.

Position: The position shows where in the record the field is located. Field 6 begins at position 30 and ends at position 33. That means that there are 29 characters preceding field 6, and field 6 occupies 4 spaces - 30, 31, 32, and 33.

Size: The size indicates the number of characters (called bits) that the field occupies. For example, field 6 is made up of 4 bits.

Picture: This is the type of bit the ACH system is expecting to see. A 9 indicates a numeric value and an X indicates an alphabetic value. If you put a letter in a PIC 9 position, the system will reject the field. If you see a number in parentheses after the X or 9, that indicates the number of characters in that field. For example 9(10) means that field contains 10 numeric characters.

Contents: This is a sample of the information or the actual information that should be included in the field. If the information is surrounded by single quote ‘1’, it is the actual information BBVA requires in that field.

Data Name: This is the name of the field. If you are building your NACHA file from scratch, you may want to use the names listed.

Comments: This is helpful information that we have included to further explain the information required in each field.

Record: Refers to the collection of fields used to represent one set of information. For example, your name, address, and phone number are individual fields of information within the record called “You.” For NACHA files, each record occupies one line.

19

Please Note: The formats outlined in this document can be used to format PPD, CCD and IAT files. If you are originating other types of ACH transactions, please refer to the most current edition of the ACH rules. For consumer ACH files (direct deposit, consumer debits) please refer to the PPD formats contained in this document. For corporate ACH files (corporate payments, corporate debits, cash concentration) please refer to the CCD formats in this document. For international ACH transactions, please refer to the IAT formats in this document.

File Header Record - The One RecordFormat: PPD, CCD, and IAT

This the first record of your ACH file.

File Header Record Format - For use with all ACH files.

Field Position Size Picture Contents Data Name Comments

1 01 1 9 ‘1’ Record Type Code

2 02-03 2 9(2) ‘01’ Priority Code

3 04-13 10 X(10) ‘062001186’ Immediate

Destination

This is BBVA’s routing number preceded by

a space.

4 14-23 10 X(10) Immediate Origin This is the ACH identification number

BBVA has established for your company.

Your treasury management officer or

implementation coordinator will provide

this information to you. It is usually one digit

followed by your company’s TIN.

5 24-29 6 9(6) YYMMDD File Creation Date This is the date your file was created.

6 30-33 4 9(4) HHMM File Creation Time This is the time your file was created in

military time.

7 34 1 X File ID Modifier This helps identify multiple files created

on the same date. A is the first file; B is the

second, etc.

8 35-37 3 9(3) ‘094’ Record Size This is the total number of characters

contained in each record within your NACHA

formatted file.

9 38-39 2 9(2) ‘10’ Blocking Factor This is the number of records that will be

imported into the ACH system at one time.

Please do not change. If the total number

of records contained in your file are not a

multiple of 10, the remaining records must

be ‘9’ filled.

10 40 1 9 ‘1’ Format Code

11 41-63 23 X(23) ‘COMPASS

BANK’

Immediate

Destination Name

This is where the file is going, the name of

your bank. Please do not change.

12 64-86 23 X(23) Your

Company

Name

Immediate

Origin Name

Put the name of your company here.

13 87-94 8 X(8) Reference Code Please leave this field blank.

20

Batch Header Record - The Five RecordFormat: PPD and CCD

You must have a batch header record for each batch in your ACH file.

PPD/CCD Batch Header Record Format



2 02-04 3 9(3) Service Class Code Select one of the following codes depending

on the type of ACH entries your are

originating:

200 debits and credits are contained in this

batch.

220 only credits are contained in this batch.

225 only debits are contained in this batch.

3 05-20 16 X(16) Company Name Put the name of your company here. Please

make sure the name matches the name in

the file header record.

4 21-40 20 X(20) Company

Discretionary Data

This field allows you to include codes for

internal purposes. This field is not used by

the ACH system.

5 41 -50 10 X(10) Company ID This is the ACH identification number






6 51 -53 3 X(3) Standard Entry Class

Code

The code you will use will depend on the type

of ACH transactions you are originating:

PPD direct deposit, consumer debit CCD

corporate payments, corporate debits, cash

concentration

7 54-63 10 X(10) Company Entry

Description

Use this field to describe the purpose of the

entry to the receiver. For example, if this

batch is for payroll, you may use ‘PAYROLL’

as the description.

8 64-69 6 X(6) YYMMDD Company

Descriptive Date

Use this optional field to show a date you

would like the Receiver to see. This field is for

descriptive purposes only and is not used to

control the timing of any operation.

9 70-75 6 X(6) YYMMDD Effective Entry Date This is the date on which you intend this

batch of ACH entries to settle.

10 76-78 3 X(3) Julian Settlement Date Leave blank. The date will be inserted by the

Federal Reserve (ACH operator).

11 79 1 9 ‘1’ Originator Status Code

12 80-87 8 X(8) ‘06200118’ Originating DFI ID This is the first 8 digits of BBVA’s routing

number.

13 88-94 7 9(7) Batch Number This should be ‘0000001’ and be

incremented by 1 for each batch in your file.

21

Batch Header Record - The Five RecordFormat: IAT

You must have a batch header record for each batch in your ACH file.

IAT Batch Header Record Format




on the type of ACH entries your are

originating:


batch.



3 05-20 16 X(16) IAT Indicator Leave blank. This is only used for notification

of changes related to IAT entries.

4 21 -22 2 X(2) ‘FF’ Foreign Exchange

Indicator

5 23 1 9 ‘3’ Foreign Exchange

Reference Indicator

6 24-38 15 X(15) Space Filled Foreign Exchange

Reference

7 39-40 2 X(2) ‘US’ ISO Destination

Country Code

8 41 -50 10 X(10) Originator ID This is the ACH identification number






9 51 -53 3 X(3) ‘IAT’ Standard Entry Class

Code


Description

Use this field to describe the purpose of the

entry to the receiver. For example, if this

batch is for payroll, you may use ‘PAYROLL’

as the description.

11 64-66 3 X(3) ‘USD’ ISO Originating

Currency Code

12 67-69 3 X(3) ‘USD’ ISO Destination

Currency Code

13 70-75 6 9(6) YYMMDD Effective Entry Date This is the date on which you intend this

batch of ACH entries to settle.

14 76-78 3 9(3) Julian Settlement Date Leave blank. The date will be inserted by the

Federal Reserve (ACH operator).

15 79 1 X ‘1’ Originator Status Code

16 80-87 8 X(8) ‘06200118’ GO Identification/

Originating DFI ID

17 88-94 7 9(7) Batch Number This should be ‘0000001’ and be

incremented by 1 for each batch in your file.

22

Entry Detail Record - The Six RecordFormat: PPD

Each record contains information about the receiver. For example, in a payroll file, each six record represents a deposit to one employee.

PPD Entry Detail Format - For use with Direct Deposit of Payroll and Consumer Debit ACH files.



2 02-03 2 9(2) Transaction Code Choose the appropriate Transaction Code

from this list:

22 live checking account credit

23 pre-note checking account credit

27 live checking account debit

28 pre-note checking account debit

32 live savings account credit

33 pre-note savings account credit

37 live savings account debit

38 pre-note savings account debit

3 04- 11 8 X(8) Receiving DFI ID This is the first eight digits of the routing

number of the bank at which your customer/

employee banks. Beware of numbers that

do not begin with a 0, 1 or 2. Those are NOT

routing numbers. Enter ‘06200118’ for PaySource CardTM entries.

4 12 1 9 Check Digit This is the last digit of the routing number.

Enter ‘6’ for PaySource Card entries.

5 13-29 17 X(17) DFI Account

Number

Your employee’s or customer’s bank account

number. Use the cardholder account number for PaySource Card entries.

6 30-39 10 9(10) $$$$$$$$¢¢ Amount This is the dollar amount you are crediting

or debiting the receiver. The decimal point is

implied, not hard coded.

7 40-54 15 X(15) Individual ID

Number

This is the identification number you assign

to your employee or customer.

8 55-76 22 X(22) Individual Name The name of your employee or customer.

9 77-78 2 X(2) Discretionary Data Use this optional field for internal purposes.

10 79 1 9 0 or 1 Addenda Record

Indicator

0 = Entry does not have an addenda record

1 = Entry has an addenda record

11 80-94 15 9(15) Trace Number First eight digits equal ‘06200118’; last seven

digits must be incremented by 1 for each

entry detail record.

23

Entry Detail Record - The Six RecordFormat: CCD

Each record contains information about the receiver. For example, in a corporate payment file, each six record represents a payment to one company.

CCD Entry Detail Format - For use with Corporate Payments, Corporate Debits and Cash Concentration.



2 02-03 2 9(2) Transaction Code Choose the appropriate transaction code

from this list:









3 04-11 8 X(8) Receiving DFI ID This is the first eight digits of the routing

number of the bank at which your customer

or vendor banks. Beware of numbers that

do not begin with a 0, 1 or 2. Those are NOT

routing numbers.


5 13-29 17 X(17) DFI Account

Number

This is your customer’s or vendor’s bank

account number.

6 30-39 10 9(8)V99 $$$$$$$$¢¢ Amount This is the dollar amount you are crediting



7 40-54 15 X(15) ID Number This is the identification number you assign

to your customer or vendor.

8 55-76 22 X(22) Receiving

Company Name

The name of the company you are debiting

or crediting.

9 77-78 2 X(2) Discretionary Data Use this optional field for internal purposes.

10 79 1 9 0 or 1 Addenda Record

Indicator

0 = Entry does not have an addenda record.

1 = Entry has an addenda record.

11 80-94 15 9(15) Trace Number First eight digits equal ‘06200118’; last seven



24

Entry Detail Record - The Six RecordFormat: IAT

Each record contains information about the receiver.

PPD/CCD Addenda Record Format



2 02-03 2 9(2) Transaction Code Choose the appropriate Transaction Code

from the list:



27 live checking account debit






3 04-11 8 C(8) GO Identification/

Receiving DFI ID

This is the routing number of the bank at

which the Receiver maintains his account.

Beware of numbers that do not begin with

a 0,1 or 2. Those are NOT routing numbers.




5 13-16 4 9(4) Number of

Addenda Records

This number represents the number of

addenda records associated with each Entry

Detail Record.

6 17-29 13 Blank Reserved

7 30-39 10 9(10) $$$$$$$$¢¢ Amount This is the dollar amount you are crediting or

debiting the Reciever. The decimal point is


8 40-74 35 X(35) Foreign Receiver’s

Account Number/

DFI Account

Number

Your employee’s, customer’s or vendor’s

account number. Use the cardholder

account number for PaySource Card entries.


10 77 1 X Space Filled Gateway Operator

OFAC Screening

Indicator

11 78 1 X Space Filled Secondary OFAC

Screening Indicator

12 79 1 9 ‘1’ Addenda Record

Indicator

13 80-94 15 X(15) Trace Number First eight digits equal ‘06200118’; last seven


Entry Detail Record.

25

Addenda Record - The Seven RecordFormat: PPD and CCD

This record is optional. It may be used if you would like to include “extra” information that the receiver needs to properly apply the entry.

PPD/CCD Addenda Record Format



2 02-03 2 9(2) ‘05’ Addenda Type Code

3 04-83 80 X(80) Payment Related

Information

This is where you place the payment

information, such as invoice number,

contract number, etc.

4 84-87 4 9(4) Addenda Sequence

Number

This number is consecutively assigned to

each addenda record following an entry

detail record. The first number must be

‘0001’.

5 88-94 7 9(7) Entry Detail

Sequence Number

This number is the same as the last seven

digits of the trace number in the related


First IAT Addenda RecordFormat: IAT

This addenda record is mandatory. It contains the name of the receiver and must be included with each IAT entry detail record.

First IAT Addenda Record Format




3 04-06 3 X(3) Transaction Type Code Select one of the following codes depending

on the type of ACH entries you are

originating:

ANN - Annuity

ARC - Accounts receivable entry*

BUS - Business/commercial

DEP - Deposit

LOA - Loan

MIS - Miscellaneous

MOR - Mortgage

PEN - Pension

26

First IAT Addenda Record Format


POP - Point of purchase entry**

RCK - Re-presented check entry*

RLS - Rent/lease

SAL - Salary/payroll

TEL - Telephone-initiated entry

WEB - internet-initiated entry

*Must include the check serial number

in the IAT addenda record for remittance

information.

**Must include the check serial number,

terminal city and terminal state/foreign

country in the IAT addenda record for

remittance information.

4 07-24 18 9(18) Foreign Payment

Amount

This is the dollar amount you are crediting



5 25-46 22 X(22) Blank Foreign Trace Number

6 47-81 35 X(35) Receiving

Company Name/

Individual Name

This is the name of the company or

individual you are crediting or debiting.



Sequence Number




Second IAT Addenda RecordFormat: IAT

This addenda record is mandatory. It contains information about the originator and must be included with each IAT entry detail record.

Second IAT Addenda Record Format




3 04-38 35 X(35) Originator Name This is the name of the originator.

4 39-73 35 X(35) Originator Street

Address

This is the physical street address of the

originator. A P.O. Box is not allowed.



Sequence Number




27

Third IAT Addenda RecordFormat: IAT

This addenda record is mandatory. It contains information about the originator and must be included with each IAT entry detail record.

Third IAT Addenda Record Format




3 04-38 35 X(35) Originator City and

State/Province

This is the city and state or province of the

originator. An asterisk (*) must be used as

the delimiter between the city and state

or province. A backslash (\) must be used

as the terminator following the state or

province.

4 39-73 35 X(35) Originator Country and

Postal Code

This is the country and postal code of the

originator. An asterisk (*) must be used as

the delimiter between the county and postal

code. A backslash (\) must be used as the

terminator following the postal code.



Sequence Number




Fourth IAT Addenda RecordFormat: IAT

This addenda record is mandatory. It contains information about the Originating Depository Financial Institution (ODFI) and must be included with each IAT entry detail record.

Fourth IAT Addenda Record Format




3 04-38 35 X(35) Originating DFI Name If your ACH file is directly funded from

outside the U.S., this is the name of the

foreign bank that originated the funding.

Otherwise enter ‘Compass Bank’.

4 39-40 2 X(2) Originating DFI ID

Number Qualifier

If your ACH file is directly funded from

outside the U.S., select one of the following

depending on the type of ODFI ID used in the

next field:

01 national clearing system number

02 bank identification number (BIC)

03 International Bank Account Number

(IBAN) otherwise enter ‘01’.

5 41-74 34 X(34) Originating DFI ID If your ACH file is directly funded from

outside the U.S., this is the routing number

or bank identification number of the foreign

bank that originated the funding. Otherwise

enter ‘062001186’.

28

Fourth IAT Addenda Record Format


6 75-77 3 X(3) Originating DFI Branch

Country Code

If your ACH file is directly funded from

outside the U.S., this is the ISO code used to

identify the country in which the branch of

the foreign bank that originated the funding

is located. For a list of codes, please go to

http://iso.org/iso/english_country_ names_

and_codes_elements. Otherwise enter ‘US’.



Sequence Number




Fifth IAT Addenda RecordFormat: IAT

This addenda record is mandatory. It contains information about the Receiving Depository Financial Institution (RDFI) and must be included with each IAT entry retail record.

Fifth IAT Addenda Record Format




3 04-38 35 X(35) Receiving DFI Name This is the name of the receiver’s bank.

4 39-40 2 X(2) ‘01’ Receiving DFI ID

Number Qualifier

5 41-74 34 X(34) Receiving DFI ID This is the routing number of the bank at

which the receiver maintains his account.

Beware of numbers that do not begin with

a 0,1 or 2. Those are NOT routing numbers.


6 75-77 3 X(3) ‘US’ Receiving DFI Branch

Country Code



Sequence Number




29

Sixth IAT Addenda RecordFormat: IAT

This addenda record is mandatory. It contains additional information about the receiver and must be included with each IAT entry detail record.

Sixth IAT Addenda Record Format




3 04-18 15 X(15) Receiver ID

Number

This is the identification number you assign

to your employee, customer or vendor.

4 19-53 35 X(35) Receiver Street

Address

This is the physical street address of the

receiver. A P.O. Box is not allowed.

5 54-87 34 X(34) Blank Reserved


Sequence Number




Seventh IAT Addenda RecordFormat: IAT

This addenda record is mandatory. It contains additional information about the receiver and must be included with each IAT entry detail record.

Seventh IAT Addenda Record Format




3 04-38 35 X(35) Receiver City and

State/Province

This is the city and state or province of the

receiver. An asterisk (*) must be used as

the delimiter between the city and state

or province. A backslash (\) must be used

as the terminator following the state or

province.

4 39-73 35 X(35) Receiver Country and

Postal Code

This is the country and postal code of the

receiver. An asterisk (*) must be used as

the delimiter between the county and postal

code. A backslash (\) must be used as the

terminator following the postal code.



Sequence Number




30

IAT Addenda Record for Remittance InformationFormat: IAT

This addenda record is normally optional and may be used to include “extra” information that the receiver needs to properly apply the entry.

This addenda record is mandatory if the Transaction Type Code in the first IAT addenda record is ARC, POP or RCK. Certain information is required for these transaction type codes as outlined below.

Note: A maximum of 2 remittance addenda records may be included with each IAT entry detail record. A maximum of 5 total addenda records for remittance information and foreign correspondent bank information (see next page) are allowed.

IAT Addenda Record for Remittance Information Format




3 04-83 80 X(80) Payment Related

Information

This is where you place the payment

information such as invoice number,

contract number, etc.

For ARC and RCK, you must place the check

serial number in this field followed by a

backslash (\) as the terminator.

For POP, you must place the check serial

number, terminal city and terminal state/

foreign country in this field. An asterisk (*)

must be used as the delimiter between the

data elements. A backslash (\) must be used

as the terminator following the terminal

state/foreign country.


Number

This number is consecutively assigned

to each addenda record for remittance

information and foreign correspondent bank

information. The first addenda sequence

number must always be ‘0001’.


Sequence Number




IAT Addenda Record for Foreign Correspondent Bank InformationFormat: IAT

Each intermediary foreign correspondent Bank involved in the funding or processing of an IAT entry must be identified within this addenda record. For example, if your ACH file is funded by foreign bank A, but foreign bank A uses foreign bank B as a correspondent or intermediary bank to deliver the funds, foreign bank B should be identified in this addenda record.

Note: A maximum of 5 total addenda records for foreign correspondent bank information are allowed.

IAT Addenda Record for Foreign Correspondent Bank Information Format




31

IAT Addenda Record for Foreign Correspondent Bank Information Format


3 04-38 35 X(35) Foreign

Correspondent Bank

Name

This is the name of the intermediary foreign

correspondent bank involved in the funding

or processing of an IAT.

4 39-40 2 Foreign

Correspondent Bank

ID Number Qualifier

Select one of the following depending on the

type of foreign correspondent ID number

used in the next field:

01 national clearing system number

02 bank identification number (BIC)

03 international bank account number

(IBAN)

5 41-74 34 Foreign

Correspondent Bank

ID Number

This is the routing number or bank

identification number of the foreign

correspondent bank involved in the funding

or processing of an IAT.

6 75-77 3 Foreign

Correspondent Bank

Branch Country Code

This is the ISO code used to identify the

country in which the branch of the foreign

correspondent bank is located. For a list

of codes, please go to http://www.iso.org/

iso/english_ country_names_and_code_

elements.



Number

This number is consecutively assigned

to each addenda record for remittance

information and foreign correspondent bank

information. The first addenda sequence

number must always be ‘0001’.


Sequence Number




Batch Control Record - The Eight RecordFormat: PPD, CCD, and IAT

This is the last data record of your batch. You should have a batch control record for each batch contained in your file.

Batch Control Record Format - For use with all ACH files





originating:


batch.



This must match the batch header record.

3 05-10 6 9(6) Entry/Addenda Count The total of all entry detail and addenda

records in the batch.

32

Batch Control Record Format - For use with all ACH files


4 11-20 10 9(10) Entry Hash This is the sum of all the RDFI routing

numbers in each entry detail record in

the batch. Sum the first 8 digits only and

truncate to the left.

5 21-32 12 9(10)V99 Total Debit Entry Dollar

Amount

This is the total dollar amount of all debit

entries contained in the batch.

6 33-44 12 9(10)V99 Total Credit Entry

Dollar Amount

This is the total dollar amount of all credit

entries contained in the batch.

7 45-54 10 X(10) Company ID This is the ACH identification number

BBVA has established for your Company.




followed by your company’s TIN. This must

match the batch header record.


9 80-87 8 X(8) ‘06200118’ Originating DFI ID This is the first 8 digits of BBVA’s routing

number.

10 88-94 7 9(7) Batch Number Same as batch header record.

File Control Record - The Nine RecordFormat: PPD, CCD, and IAT

This is the last data record of your NACHA file.

File Control Record Format - For use with all ACH files



2 02-07 6 9(6) Batch Count This is the total number of ACH batches

included in the file.

3 08-13 6 9(6) Block Count This is the total number of blocks included in

the file. The block count x 10 = total number

of records.

4 14-21 8 9(8) Entry/Addenda Count This is the total number of entry detail and

addenda records in the file.

5 22-31 10 9(10) Entry Hash This is the sum of all the RDFI routing

numbers in each entry detail record in the

file. Sum the first 8 digits only and truncate

to the left.

6 32-43 12 9(10)V99 Total Debit Entry Dollar

Amount in File

This is the total dollar amount of all debit

entries in the file.


Dollar Amount in File

This is the total dollar amount of all credit

entries in the file.


33

NACHA File Format - Returns and Notifications of Change (NOC)

General InformationThe formats outlined in this document are used for Return and Notifications of Change (NOC) ACH files. These formats were established by the National Automated Clearing House Association (NACHA) and are subject to change. Please consult the most current edition of the ACH Rules published by NACHA to ensure you are using the most up-to-date NACHA file format.

The formats outlined in this document are used for returns and NOCs related to PPD and CCD entries. If you originated other types of ACH transactions, please refer to the most current edition of the ACH Rules.

Field: A field is a group of characters or numbers that represent one piece of information. For example, field 6 in the file header record contains the time your ACH file was created.

Position: The position shows where in the record the field is located. Field 6 begins at position 30 and ends at position 33. That means that there are 29 characters preceding field 6, and field 6 occupies 4 spaces - 30, 31, 32, and 33.

Size: The size indicates the number of characters (called bits) that the field occupies. For example, field 6 is made up of 4 bits.

Picture: This is the type of bit the ACH system is expecting to see. A 9 indicates a numeric value and an X indicates an alphabetic value. If you put a letter in a PIC 9 position, the system will reject the field. If you see a number in parentheses after the X or 9, that indicates the number of characters in that field. For example 9(10) means that field contains 10 numeric characters.

Contents: This is a sample of the information or the actual information that should be included in the field. If the information is surrounded by single quote ‘1’, it is the actual information BBVA requires in that field.

Data Name: This is the name of the field. If you are building your NACHA file from scratch, you may want to use the names listed.

Comments: This is helpful information that we have included to further explain the information required in each field.

Record: Record refers to the collection of fields used to represent one set of information. For example, your name, address, and phone number are individual fields of information within the record called “You.” For NACHA files, each record occupies one line.

Please Note: For consumer ACH files (direct deposit, consumer debits) please refer to the PPD and RCK formats contained in this document. For corporate ACH files (corporate payments, corporate debits, cash concentration) please refer to the CCD formats contained in this document.

Sample NACHA Formatted Return/NOC File

34

File Header Record - The One RecordFormat: PPD and CCD for both returns and notifications of change.

Each field of the File Header Record is the same as the original entry as follows:

File Header Record Format - (TAPE-HEAD-BODY)



2 02-03 2 9(2) ‘01’ Priority Code

3 04-13 10 X(10) ‘062001186’ Immediate

Destination

This is BBVA’s routing number preceded by

a space.

4 14-23 10 X(10) Immediate Origin This the ACH identification number






5 24-29 6 9(6) YYMMDD File Creation Date This is the date your original file was created.

6 30-33 4 9(4) HHMM File Creation Time This is the time your original file was created

in military time.

7 34 1 X File ID Modifier This helps identify multiple files created

on the same date. A is the first file; B is the

second, etc.

8 35-37 3 9(3) ‘094’ Record Size This is the total number of characters

contained in each record within your original

NACHA formatted file.

9 38-39 2 9(2) ‘10’ Blocking Factor This is the number of records that will be

imported into the ACH system at one time.

Please do not change. NOTE: If the total

number of records contained in your file are

not a multiple of 10, the remaining records

must be ‘9’ filled.

10 40 1 9 ‘1’ Format Code

11 41-63 23 X(23) ‘COMPASS

BANK’

Immediate Destination

Name

This is where the original file went - the name

of your bank. Please do not change.

12 64-86 23 X(23) Your

Company

Name

Immediate Origin

Name

This is your company name as included in

your original file.

13 87-94 8 X(8) Not Used

35

Batch Header Record - The Five RecordFormat: PPD and CCD for both Returns and Notifications of Change.

Each field of the Batch Header Record is the same as the original entry unless otherwise noted as follows:

Batch Header Record Format - (COMPANY-HEAD-BODY REDEFINES TAPE-HEAD-BODY)



2 02-04 3 9(3) Service Class Code 200 debits and credits were contained in the

original batch.

220 only credits were contained in the

original batch.

225 only debits were contained in the

original batch.

3 05-20 16 X(16) Company Name This is your company name as included in

your original batch.

4 21-40 20 X(20) Company

Discretionary Data

The discretionary data included in your

original batch, if any, is shown here.

5 41-50 10 X(10) Immediate Origin This is the ACH identification number


Your treasury management officer and




6 51-53 3 X(3) Standard Entry Class The code shown depends on the type of ACH

transactions you are originating and whether

the batch contains returns or NOCs:

PPD returns for direct deposit, consumer

debit

CCD returns for corporate payments,

corporate debits, cash concentration

COR all NOCs


Description

This field contains the entry description from

your original Batch ID, buy may contain the

identification of the ACH operator (Federal

Reserve).

8 64-69 6 X(6) YYMMDD Company

Descriptive Date

The descriptive date included in your original

batch, if any, is shown here.

9 70-75 6 X(6) YYMMDD Effective Entry Date Effective date intended, often next day or

future dated transactions. See “Same Day

ACH Origination” on page 39 for more

information.

REDEFINES ENTRY-DAT-CH

YEAR-1 PIC 99; MONTH-1 PIC 99; FILLER

PIC XX

10 76-78 3 X(3) Julian Settlement Date This date was inserted by the ACH operator

(Federal Reserve).

11 79 1 9 ‘1’ Originator Status Code Changed to reflect the originator status of

the bank initiating the return or NOC.

12 80-87 8 X(8) ‘06200118’ Originating DFI ID Changed to reflect the routing number of the

bank initiating the return or NOC.

13 88-94 7 9(7) Batch Number Changed to the batch number assigned by

the bank initiating the return or NOC.

36

Entry Detail Record - The Six RecordFormat: PPD for both Returns and Notifications of Change

PPD and RCK Entry Detail Format - (DETAIL-REC-BODY)


1 01 1 9 ‘6’ ‘6’ Record Type Code

2 02-03 2 9(2) Transaction Code Changed to the appropriate return or NOC

outlined below.

3 04-11 8X (8) ‘06200118’ Receiving DFI

Identification

This is the first eight digits of the routing

number of the bank receiving the return or

NOC. Since the item is coming back to BBVA,

you should see 0620018.

4 12 1 9 ‘6’ Check Digit This is the last digit of BBVA’s routing

number.

5 13-29 17 X(17) DFI Account

Number

This is your employee’s or bank’s account

number.

6 30-39 10 9(8)V99 $$$$$$$$99 Amount The dollar amount of the item you originated.

If the item is a NOC, it will be zero.

7 40-54 15 X(15) Individual ID

Number

The identification numbers of your

employees or customers as included on the

original entry.

8 55-76 22 X(22) Individual Name The name of your employee or customer as

included on the original entry.

9 77-78 2 X(2) Discretionary Data Discretionary data included in original entry,

if any.

10 79 1 X ‘1’ Addenda Record

Indicator

Indicates that there is additional information

related to this record.

11 80-94 15 9(15) Trace Number Assigned by the bank originating the return

or NOC.

Transaction Codes Used in Return and Notification of Change NACHA Files21 Checking account automated return or NOC for original transaction codes 22, 23, or 24.

26 Checking account automated return or NOC for original transaction codes 27, 28, or 29.

31 Savings account automated return or NOC for original transaction codes 32, 33, or 34.


Entry Detail Record - The Six RecordFormat: CCD for both Returns and Notifications of Change




2 02-03 2 9(2) Transaction Code Changed to the appropriate return or

notification of change code outlined below.

3 04-11 8 X(8) ‘ 06200118 ’ Receiving DFI

Identification

This is the first eight digits of the routing

number of the financial institution receiving

the return or NOC. Since the item is coming

back to BBVA, you should see 0620018.

4 12 1 9 ‘6’ Check Digit This is the last number of BBVA’s routing

number.

37



5 13-29 17 X(17) DFI Account

Number

This is your customer’s bank account

number.

6 30-39 10 9(8)V99 $$$$$$$$99 Total Amount The dollar amount of the item you originated.

If the item is NOC, it will be zero.

7 40-54 15 X(15) Identification

Number

The identification number of your customer

as included on the original entry.

8 55-58 4 9(4) Number of

Addenda Records

The number of addenda records contained

in this file.

9 59-74 16 X(16) Receiving

Company Name/ ID

Number

The name of your customer as included on

the original entry.

10 75-76 2 X(2) Reserved Blank field.

11 77-78 2 X(2) Discretionary Data Discretionary data as included on the

original entry, if any.

12 79 1 9 ‘1’ Addenda Record

Indicator

Indicates that there is additional information

related to this record.

13 80-94 15 9(15) Trace Number Assigned by the bank originating the return

or NOC.

Transaction Codes Used in Return and Notification of Change NACHA Files21 Checking account automated return or NOC for original transaction codes 22, 23, or 24.

26 Checking account automated return or NOC for original transaction codes 27, 28, or 29.



Addenda Record - The Seven Record (Return Entries)Format: PPD and CCD for Return Entries

This record contains the information you need to appropriately handle the returned ACH entry.

Addenda Record Format - (DETAIL-REC-BODY)




3 04-06 3 X(3) Return Reason Code This is why the item is being returned. Please

refer to the return codes located in your ACH

user guide.

4 07-21 15 9(15) Original Entry Trace

Number

This number matches the trace number

contained in the original entry.

5 22-27 6 X(6) YYMMDD Date of Death This field is only used with return codes R14

and R15.

6 28-35 8 X(8) Original Receiving

DFI Identification

The routing number of your employee’s or

customer’s bank.

7 36-79 44 X(44) Addenda

Information

Blank field

8 80-94 15 9(15) Trace Number The trace number of this transaction, as

entered by the bank originating this return

item.

38

Addenda Record - The Seven Record (NOC)Format: PPD and CCD for Notifications of Change

This record contains the information you need to appropriately handle your notification of change. Note: you must make the requested change within six business days, or prior to the next time you transmit the entry, whichever is later.

Addenda Record Format - (DETAIL-REC-BODY)




3 04-06 3 X(3) Change Code This code identifies what needs to be

changed in your original ACH entry. Please

refer to the list of NOC codes located in your

ACH user guide.

4 07-21 15 9(15) Original Entry Trace This number matches the trace number

contained in the original entry.

5 22-27 6 X(6) Reserved Blank field

6 28-35 8 X(8) Original Receiving DFI

Identification

The routing number of your employee’s or

customer’s bank.

7 36-64 29 X(29) Corrected Data This is the correct information that needs

to be updated in your records prior to

submitting another ACH entry.

8 65-79 15 X(15) Reserved Blank field

9 80-94 15 9(15) Trace Number The trace number of this transaction, as

entered by the bank originating this return

item.

Batch Control Record - The Eight RecordFormat: PPD and CCD for both Returns and Notifications of Change

Note: Each field of the batch control record is the same as the original entry as follows:

Batch Control Trailer Format - (GEN-FOOT-BODY REDEFINES TAPE-HEAD-BODY)



2 02-04 3 9(3) Service Class Code

SERV-CODE-GF

Select one of the following codes depending


originating:


batch.



Must match batch header record

3 05-10 6 9(6) Entry Addenda Count

ITEM-COUNT

The total of all six and seven records present

within a batch.

4 11-20 10 9(10) Entry Hash

ENTRY-HASH

This is the sum of all the RDFI routing

numbers in each six record. Sum the first 8

digits only and truncate to the left.

5 21-32 12 9(10)V99 Total Debit Entry

TOTAL-DB

This is the total of all debit entries contained

in the file.

39

Batch Control Trailer Format - (GEN-FOOT-BODY REDEFINES TAPE-HEAD-BODY)



TOTAL-CR

This is the total of all credit entries contained

in the file.

7 45-54 10 X(10) Company ID

Number

ID-GF

The ID number BBVA uses to identify

your company. This number is provided

by your treasury management officer or

implementation coordinator.

8 55-79 25 X(25) Not Used

FILLER

9 80-87 8 X(8) ‘06200118’ Originating DFI ID

TRACE-GF PIC X(8)

The first 8 digits of BBVA’s routing number.

10 88-94 7 9(7) Batch Number Same as batch header record

File Control Record - The Nine RecordFormat: PPD and CCD for both Returns and Notifications of Change

Note: Each field of the file control record is the same as the original entry as follows:

File Control Trailer Format - (TAPE-FOOT-BODY REDEFINES TAPE-HEAD-BODY)



2 02-07 6 9(6) Batch Count This is the total number of ACH batches

included in the file.

3 08-13 6 9(6) Block Count This is the total number of blocks included in

the file. The block count x 10 = total number

of records.

4 14-21 8 9(8) Entry/Addenda Count This is the total number of entries contained

in your original file. (The total number of six

records).

5 22-31 10 9(10) Entry/Hash This is the sum of all the RDFI routing

numbers in each six record of your original

file . Sum the first 8 digits only and truncate

to the left.

6 32-43 12 9(10)V99 Total Debit Entry This is the total of all debit entries contained

in your original file.

7 44-55 12 9(10)V99 Total Credit Entry This is the total of all credit entries contained

in your original file.

8 56-94 39 X(39) Blank Not Used

Same Day ACH Origination

Transaction Type Availability Origination Deadlines

Conditions and Restrictions

Same Day On-Us ACH

(Debit and credit parties using BBVA

accounts)

Available Now 6:00 p.m. CT

ACH business days

Debits and Credits

All valid ACH transaction amounts

and SEC Codes

No opt-in required

40

Transaction Type Availability Origination Deadlines

Conditions and Restrictions

Same Day ACH Debits and Credits

(Interbank) 1,2

Available Now for Originated and

Received Items

IMPORTANT: Opt-in is required

for interbank same day ACH

origination 2

First Window

7:30 a.m. CT

Second Window 11:30

a.m. CT4

ACH business days

International ACH (IAT)

transaction types are not

eligible for interbank, same day

processing 5

Limit $25,000 per transaction 3

1 While ACH participating banks are able to receive same day ACH items, some government agencies and other trading partners may not be ready to post your payments on a same day basis. Please contact these entities directly for information regarding their capabilities and policies. Unless otherwise mutually agreed, in the event of a system interruption or outage, same day items will be processed through the next available window which may result in a delay in settlement by one business day. Starting March 16, 2018, all ACH participating financial institutions must make received same day ACH transactions available by 5 p.m. of the effective date (institution local time). Additional fees may apply. Subject to credit approval.

2 Opting in as an originator for credits and opting in for debits are two separate steps; each entity must be opted in for interbank debit or credit origination as appropriate. For more information, details, and fee information, contact your Treasury Management Sales Officer, or go to the Same Day ACH FAQ at https://www.bbvausa.com/go/samedayach/. Additional fees may apply. Subject to credit approval.

3 Transactions greater than $25,000 will be re-batched and processed the next business day; all same day ACH rule-conforming items in the original batch will be processed on the same day as indicated by the effective entry date indicated in the batch header record for batches that are delivered to the bank by the intra-day deadline on ACH business days.

4 Due to Internet delay, it is recommended that files are sent no later than 5 minutes prior to the deadline.

5 Interbank IAT transactions which are effective dated for same day processing will be processed on the next available business day.

41

Bank Statements (DDA)Customers can download a copy of their regular bank statement (sometimes referred to as the DDA statement) as BBVA Net Cash USA in either and eStatement in PDF format or in text format using the Electronic Reports Services. Customers may also receive PDF bank statements through our Host-to-Host or File Transfer Services channels. Shown below is a sample of the report.

42

Balance and Transaction ReportingYou can obtain a file of all the balances and transactions posting to your account.

If you obtain the file from BBVA Net Cash, you can specify the date ranges, balance types (status balances, summary totals, detail credit transactions and detail debit transactions), transaction type (check paid, etc.), and amount ranges.

Some customers want to receive an automated download every day in BAI II standard format. This is available through one of our Direct Channels transmission channels (File Transfer Services or BBVA e-Transmit).

Formats Available on BBVA Net CashYou can download your balance and transaction information from BBVA Net Cash in the following formats: BAI II standard, comma delimited (CSV), CS basic (CSB), PDF, or Swift MT940/942. From BBVA Net Cash, you may also download balances and transactions using WebConnect into your QuickenTM or QuickbooksTM applications in OFX format. Shown below is a sample BAI II standard file:

Custom Format or Automated DownloadIf you need a file in a format not listed above and/or you want to receive the file in an automated manner using schedulers, you will need to use one of the Direct Channels transmission methods (File Transfer Services or BBVA e-Transmit).

The BAI II standard file available through one of the Direct Channels transmission methods is sorted by date and transaction posting order. It will look very similar to the sample BAI II standard file shown above.

43

BBVA e-LockboxCustomers using BBVA e-Lockbox have the ability to receive a daily file Accounts Receivable file of all payments received that business day, in order to easily update their accounts receivable system. See below for the file layout.

Payment Exchange Super Format LayoutFormat: Comma Separated, Quote Qualified

Field Description Notes Field Type Max Length

1 Client ID Client ID alphanumeric 16

2 Client Name Client’s DBA name alphanumeric 45

3 Account Number Payment account number alphanumeric 64

4 Amount Payment amount, decimal is only included when needed numeric and decimal (.) 10

5 Process Date Payment process date “YYYY-MM-DD” alphanumeric 10

6 Settlement Date Biller deposit date “YYYY-MM-DD” alphanumeric 10

7 Group ID Group ID- client specified alphanumeric 16

8 Group Description Group name- client specified alphanumeric 255

9 Transaction ID Unique transaction # numeric 11

10 Customer First Name Customer’s first name, sent by originator alphanumeric 50

11 Customer Middle

Initial

Customer’s middle initial, sent by originator alphanumeric 1

12 Customer Last Name Customer’s last name, sent by originator alphanumeric 50

13 Customer Address 1 Customer’s street address, sent by originator alphanumeric 35

14 Customer Address 2 Customer’s address 2, sent by originator alphanumeric 35

15 Customer City Customer city, sent by originator alphanumeric 30

16 Customer State Customer state, sent by originator alphanumeric 2

17 Customer Zip Customer zip code, sent by originator- format is either

#####-#### or #####

numeric and dash (-) 10

* Depending on originator, the customer’s middle initial and all five customer address fields may be empty. ** If payment grouping is not being utilized, the group ID and group name fields will be empty.

Sample (2 Records)

“ES12345TP-01”,”ABC Company”,”12345-1234567890”,1234.56,”2016-07-26”,”2016-07-27”,”0001”,”Tax Payments”,”77474387”,”John”,”A”,”Test”,”123 Main St”,””,”Anytown”,”MN”,”12345”

“ES12345TP-01”,”ABC Company”,”54321-0000054321”,50.00,”2016-07-26”,”2016-07-27”,”0001”,”Tax Payments”,”77474389”,”Mary”,””,”Johnson”,”421 Test Ave”,””,”Smallville”,”GA”,”54321”

44

Controlled DisbursementControlled disbursement reporting information is available through either BBVA Net Cash or using one of the Direct Channels transmission methods (File Transfer Services or BBVA e-Transmit).

Our Controlled Disbursement sites are provided below:

• Oxford, AL

• Flagstaff, AZ

• Fort Collins, CO

• Pensacola, FL

• Rio Rancho, NM

• Lake Jackson, TX

All sites have a single daily presentment of 9:00 a.m. CT.

BAI CodesListed below are the BAI codes that BBVA uses in the controlled disbursement file:

700 DETAIL DB INDIVIDUAL CONTROLLED DISBURSING DEBIT (1ST PRESENTMENT)

701 DETAIL DB INDIVIDUAL CONTROLLED DISBURSING DEBIT (2ND PRESENTMENT)

702 SUMMARY DB TOTAL DISBURSING CHECKS PAID - EARLY AMOUNT (1ST PRESENTMENT)

703 SUMMARY DB TOTAL DISBURSING CHECKS PAID - LATER AMOUNT (2ND PRESENTMENT)

704 SUMMARY DB PREVIOUS DAY CDA MISMATCH TOTAL

705 SUMMARY DB PREVIOUS DAY CDA MISMATCH DETAIL

BBVA Net Cash ReportingControlled disbursement information is reported in the information reporting services. You can receive either summary information to notify you of your funding requirements for the day, or you can get a detail list of checks which will be posting to your account that day. Information can be downloaded in the following formats: BAI II standard, comma delimited (CSV) or CS basic (CSB), MT 942 or PDF format. This download cannot be automated.

Direct Channels ReportingSome customers want to receive an automated download every day in BAI II standard format. The BAI II standard file available using one of the Direct Channel transmission methods (File Transfer Services or BBVA e-Transmit) is sorted by date and transaction posting order.

Electronic Bill Presentment and Payment (EBPP)BBVA’s EBPP can provide a daily Accounts Receivable file, which contains all payments made in EBPP prior to the system cut off. The Accounts Receivable file allows clients to easily update their accounts receivables system. See below for the file layout for the Accounts Receivable file.

Extended Standard A/R File Format SpecificationsAn extended version of the Standard A/R File meets business requirements for extended length reporting on Account Number, Biller Invoice Number and inclusion of reporting on Depository information by adding the following fields to the A/R File:

• ACH Company ID

• ACH Company Name

• Routing Transit Number (Biller)

• DDA Account Number

• CC MID

Note: Depository information is not mandatory so any Biller can use this extended version of the Standard A/R File without needing to provide the depository information.

Note: The Extended Standard A/R File Format has an increased block size of 550 bytes. There are no other changes in behavior, supported functionality and file layout definition in comparison to the Standard A/R file.

45

File Layout Definition

File Header Record LayoutOne header record per file transmission

Field Name Position Length Type Data

Record Code 1 1 A

Partner Name 2 16 A Partner Short Name

File Creation Date 18 8 A Date file was created in format CCYYMMDD

File Creation Time 26 4 A Time file was created in format HHMM

File type 30 4 A ‘PROD’ or ‘MEMO’, depending upon whether it is a

payment or memo posting file

Filler 34 517 A Spaces

Batch Header Record LayoutOne batch header record per file transmission

Field Name Position Length Type Data

Record Code 1 1 A ‘5’

Client ID 2 10 A Transactis assigned Client ID

Biller Name 12 12 A Biller Name

Batch Number 24 7 N Sequential number of batch in file


Payment Detail Record Layout

Field Name Position Length Type Data Name


Transaction type 2 2 A Type of transaction. Allowed types are:

50 Regular payment

53 Payment reversal

Reversal reason code 4 3 A To be populated whenever Transaction Type = 53. Use

one of the following: NACHA Return Reasons code will

be used

Payment ID 7 19 A Confirmation number of payment

Account number 26 100 A Account Number on the Invoice being paid. In case a

single payment spans multiple invoices for Users who

have Multiple Accounts, the Account number value on

the ‘6’ must reflect Account Numbers on the invoice

this ‘6’ record refers to.

Payment amount 126 10 N Payment or payment reversal amount. All amounts

should be shown as positive numbers regardless of

the transaction type, with 2 implied decimal places.

Fee amount 136 10 N Fee or fee reversal amount. All amounts should

be shown as positive numbers regardless of the

transaction type, with 2 implied decimal places.

Total Transaction Amount 146 10 N Payment amount plus Fee amount. All amounts



Tender Type 156 3 A ‘USD’, and for future use

46


Payment Date 159 8 A Effective date of payment, format CCYYMMDD

Customer Name 167 22 A Customer’s Name

Customer E-mail 189 50 A Customer’s primary e-mail address

Customer Phone 239 20 A Customer’s primary phone number

Customer Cell Phone 259 20 A Customers’ cell phone number

Transaction date 279 8 A Date transaction was created, format CCYYMMDD

Transaction time 287 6 A Time transaction was created, format HHMMSS,

military time.

Detail Sequence number 293 6 N Begin 1 on the first detail record, and add 1 for each

additional record in the Batch.

Biller Invoice Number 299 50 A Biller Invoice Number passed from Customer Billing

File

Payment Source 349 3 A CSR – Payment captured by CSR, either Enrolled or

Unenrolled

WEB – Payment captured by web interface

IVR – Payment captured by IVR interface

Payment Mechanism 352 3 A ENR – Enrolled Consumer

UNE – Unenrolled Consumer

Payment Method 355 1 A A=ACH

C=Credit Card\Visa & MC Debit

D=ATM/Debit

Payment Account/Card Type 356 2 A ACH

PC=Personal Check

PS=Personal Savings

BC=Business Check

BS=Business Savings Credit/Debit Card

AX=American Express

DI=Discover

VI=Visa

MC = Master Card

Last 4 of payment account 358 4 A Last 4 digits of payment account #, ACH Account

number, CC number or ATM/DC number.

Credit card expiration date 362 4 N Credit card expiration date – format MMYY

Credit card authorization code 366 6 N Credit card authorization code returned by merchant

processor

ATM Trace ID 372 12 A Trace ID provided by the ATM network; identifies

transaction for research purposes

Short Pay Reason Code 384 6 A Short Pay Reason Code for the payment.

SEC Code 390 3 A This is the ACH Standard Entry Class Code

FDI Code 393 20 A This is the Funds Direction Code that is passed from

Bill File

ACH Company ID 413 10 A ACH Company ID (Only on ACH transactions)

ACH Company Name 423 16 A ACH Company Name (Only on ACH transactions)

Routing Transit Number 439 9 N Depository Bank Routing Number (Only on ACH

transactions)

DDA Account 448 17 N DDA Account Number (Only on ACH transactions)

47


CC MID 465 32 A Credit Card Payment MID (Only on CC transactions)

Principal Payment or Fee Payment MID (Only on CC

transactions)


Payment Addenda Record Layout

Supplemental Record 70

One detail supplemental record per individual Invoice Payment for Billers who provide defined remittance fields in their billing file. For ACH return and Credit Card refunds, the value in the payment ID will contain the original Payment ID number vs. the return or refund Payment ID.




70 Supplemental Record

Filler 4 3 A Blank


Account number 26 100 A Same as on the corresponding ‘6’ record this

“Supplemental Record” applies to.

Biller Remittance Field 1 126 50 N Data passed by the Biller as Biller Remittance Field 1






Supplemental Record 71

Note: This section is applicable only to those payments which have Payment Free Form text comment not blank. One detail supplemental record per individual Invoice Payment. For ACH return and Credit Card refunds, the value in the payment ID will contain the original Payment ID number vs. the return or refund Payment ID.





Filler 4 3 A Blank




Short Pay Reason 126 250 A Short Pay Detail Text for the payment, entered by the

consumer for that individual short pay.


48

Credit Memo Processing

If Partner allowed and Biller enabled, Credit Memo transactions will be recorded and reported via AR file. Below find layout definitions for both Detail and Addendum records.

Credit Memo Detail Record Layout Data Types:

Numeric (N) Right justified, leading zeroes

Alpha Numeric (A) Left justified, padded with spaces

Note new account number length definition, DDA/CC fields added. New Record length 550.



Transaction type 2 2 A Transaction Types Allowed:

55 Credit Memo

56 Return Credit Memo

Reversal reason code 4 3 A To be populated when Transaction Type = 56.

Use one of the following:

NACHA Return Reasons code (Use same code as for

the payment returned)


Account number 26 100 A Biller account number

Payment amount 126 10 N Payment or payment reversal amount. All amounts



Fee amount 136 10 N N/A

Total Transaction Amount 146 10 N Credit Memo amount. All amounts should be shown

as positive numbers regardless of the transaction

type, with 2 implied decimal places.

Tender Type 156 3 A ‘USD’, and for future use

Payment Date 159 8 A Effective date of payment, format CCYYMMDD

Customer Name 167 22 A Customer’s Name

Customer E-mail 189 50 A Customer’s primary e-mail address

Customer Phone 239 20 A Customer’s primary phone number

Customer Cell Phone 259 20 A Customers’ cell phone number

Transaction date 279 8 A Date transaction was created, format CCYYMMDD

Transaction time 287 6 A Time transaction was created, format HHMMSS,

military time.

Detail Sequence number 293 6 N Begin 1 on the first detail record, and add 1 for each

additional record in the Batch.

Biller Invoice Number 299 50 A Biller Invoice Number passed from Customer Billing

File

Payment Source 349 3 A Use payment source for the payment

CSR – Payment captured by CSR, either Enrolled or

Unenrolled

WEB – Payment captured by web interface

IVR – Payment captured by IVR interface

49


Payment Mechanism 352 3 A Use payment source for the payment

ENR – Enrolled Consumer

UNE – Unenrolled Consumer

Credit Memo Reason Code 355 6 A Credit Memo Reason Code

ACH Company ID 361 10 A ACH Company ID (Only on ACH transactions)

ACH Company Name 371 16 A ACH Company Name (Only on ACH transactions)

Routing Transit Number 387 09 N Depository Bank Routing Transit Number (Only on

ACH transactions)

DDA Account 396 17 N DDA Account Number (Only on ACH transactions)

CC MID 413 32 A Credit Card Payment MID (Only on CC transactions)

Principal Payment or Fee Payment MID (Only on CC

transactions)


Credit Memo Addendum Record Layout

(Standard A/R) Data Types:

Numeric (N) Right justified, leading zeroes

Alpha Numeric (A) Left justified, padded with spaces





Filler 4 3 A Blank











Transaction type 2 2 A Transaction Types Allowed:

Supplemental Record

Filler 4 3 A Blank


Account number 26 100 A Consumer’s account number

Credit Memo and Payment Text if

enabled

126 250 A Reasoning Detail Text for the payment, entered by the

consumer for that individual payment.


50

Batch Trailer Record Layout

Increased block size in reference to Standard A/R File.

One per batch, after each group of detail records representing one batch. Payments should be batched by Biller.



Batch Detail Count 2 10 N Total number of detail records in the batch, zero-filled

Batch Debit Total 12 12 N Total of Debit payment amounts in the batch. All

amounts should be shown as positive numbers,

regardless of the transaction type, with 2 implied

decimal places

Batch Credit Total 24 12 N Total of Credit payment amounts in the batch. All

amounts should be shown as positive numbers,

regardless of the transaction type, with 2 implied

decimal places

Batch Number 36 7 N Should match Batch Header Number


File Trailer Record Layout

Increased block size in reference to Standard A/R File.

One record per file



Total Batch File 2 6 N Total Number of Batches in the file

Total Detail File 8 12 N Total Number of Detail records in the file

Total Debit File 20 12 N Total of Debit payment amounts in the file. All amounts

should be shown as positive numbers, with 2 implied

decimal places

Total Credit File 32 12 N Total of Credit payment amounts in the file. All

amounts should be shown as positive numbers, with 2

implied decimal places

51

Electronic Data Interchange (EDI)EDI transaction information may be delivered by the ERD module or in NACHA format.

Electronic Report Delivery (ERD)Customers can receive an electronic version of paper reports using the BBVA Net Cash Electronic Reports Services. The reports may be viewed online or printed, but not downloaded in data format. Shown below is an example of an EDI report posted on ERD.

NACHA FormatEDI transaction information delivered in the standard NACHA format is only available through one of the Direct Channel methods. It is not available through BBVA Net Cash.

52

Image Cash Letter (ICL)The BBVA data transmissions guide file specifications are intended for the technical personnel within your company. This guide provides information and record layouts for formatting the entries you initiate through our ICL service when using BBVA as the bank of first endorsement. The information below is a variant of the American National Standard for Financial Services, Accredited Standards Committee X9’s Specifications for Electronic Exchange of Check and Image Data Draft Standard for Trail Use (DSTU) X9.37-2003. The information below describes the format of the BBVA DSTU X9.37-2003 variant image cash letter file you will send to us as part of your service.

File Naming ConventionEach file transmitted must have a unique name and must include a time stamp HHMMSS. No spaces or special characters are permitted.

File Header Record (Type 01)The File Header Record is mandatory and contains fourteen fields. It is the first record of the file. The data in the fields are created by the institution sending the file, the immediate origin institution.

Field Field Name Usage Position Size Type

1

2

3

4

5

6

7

8

9

10

11

12

13

14

Record Type

Standard Level

Test File Indicator

Immediate Destination Routing Number

Immediate Origin Routing Number

File Creation Date

File Creation Time

Resend Indicator

Immediate Destination Name

Immediate Origin Name

File ID Modifier

Country Code

User Field

Reserved

M

M

M

M

M

M

M

M

C

C

C

C

C

M

01 - 02

03 - 04

05 - 05

06 - 14

15 - 23

24 - 31

32 - 35

36 - 36

37 - 54

55 - 72

73 - 73

74 - 75

76 - 79

80 - 80

2

2

1

9

9

8

4

1

18

18

1

2

4

1

N

N

A

N

N

N

N

A

A

A

AN

A

ANS

B

Note: All fields that are conditional and are not used shall be filled with blanks.

Record Type

A code that identifies the type of record.

Note: This is a variable length record file.

Usage

Position

Size

Type

Defined Values

Mandatory

01 - 02

2

N Numeric

‘01’ File header record

53

Standard Level

A code that identifies the version of the standard used to

create the file.

Usage

Position

Size

Type

Defined Values

Mandatory

03 - 04

2

N Numeric

‘01’ X9.37–1994

‘02’ X9.37-2001

‘03’ X9.37-2003

Test File Indicator

A code that indicates whether the file being transmitted is

a test file or a production file.

Usage

Position

Size

Type

Defined Values

Mandatory

05 - 05

1

A Alphabetic

‘P’ Production file

‘T’ Test file

Immediate Destination Routing Number

A number that identifies the institution that receives the

file.

Usage

Position

Size

Type

Defined Values

Mandatory

06 - 14

9

N Numeric

TTTTAAAAC, where:

TTTT Federal reserve prefix

AAAA ABA institution identifier

C Check digit

Alternate format for a number that identifies a

non-financial institution:

NNNNNNNNN

Immediate Origin Routing Number

A number that identifies the institution that originates the

file.

Usage

Position

Size

Type

Defined Values

Mandatory

15 - 23

9

N Numeric

TTTTAAAAC, where:



C Check digit

Alternate format for a number that identifies a

non-financial institution:

NNNNNNNNN

54

File Creation Date

The year, month, and day that the immediate origin

institution creates the file.

Usage

Position

Size

Type

Defined Values

Mandatory

24 - 31

8

N Numeric

YYYYMMDD, where:

YYYY year

MM month

DD day

YYYY‘1993’ through ‘9999’

MM ‘01’ through ‘12’

DD ‘01’ through ‘31’

File Creation Time

The time the immediate origin institution creates the file. Usage

Position

Size

Type

Defined Values

Mandatory

32 - 35

4

N Numeric

hhmm, where:

hh hour

mm minute

hh ‘00’ through ‘23’

mm ‘00’ through ‘59’

Resend Indicator

A code that indicates whether the file has been previously

transmitted in its entirety.

Usage

Position

Size

Type

Defined Values

Mandatory

36 - 36

1

A Alphabetic

‘Y’ resend file – File contains the same data as a

previously sent file.

‘N’ original file – This is the original file.

Immediate Destination Name

The short name that identifies the institution that

receives the file.

Usage Conditional

Shall be present, unless omitted under clearing

arrangements.

Position

Size

Type

37 - 54

18

A Alphabetic

55

Immediate Origin Name

The short name that identifies the institution that sends

the file.

Usage Conditional


arrangements.

Position

Size

Type

55 - 72

18

A Alphabetic

File ID Modifier

A code that permits multiple files, created on the same

date, same time, and between the same institutions, to be

distinguished one from another. Value must be unique for

each file created.

Usage Conditional

Shall be present, if all of the following fields in a

previous file are equal to the same fields in this file:

file header record (Type 01), field 4, field 5, field 6,

and field 7.

Position

Size

Type

73 – 73

1

AN Alphameric

Country Code

A code that identifies the country in which the payor bank

is located.

Usage Conditional

Shall be present only under clearing

arrangements.

Position

Size

Type

74 - 75

2

A Alphabetic

User Field

A field used at the discretion of users of the standard. Usage Conditional


arrangements.

Position

Size

Type

76 - 79

4

ANS Alphameric/Special

Reserved

A field reserved for future use by the Accredited

Standards Committee X9.

Usage

Position

Size

Type

Mandatory

80 - 80

1

B Blank

56

Cash Letter Header Record (Type 10)

The cash letter header record is mandatory and contains fifteen fields. It always follows a file header record (Type 01) unless a file contains multiple cash letters then the cash letter header record shall follow a cash letter control record (type 90). The data in the fields are created by the ECE institution, which may or may not be the bank of first deposit (BOFD).


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

Record Type

Collection Type Indicator

Destination Routing Number

ECE Institution Routing Number

Cash Letter Business Date

Cash Letter Creation Date

Cash Letter Creation Time

Cash Letter Record Type Indicator

Cash Letter Documentation Type Indicator

Cash Letter ID

Originator Contact Name

Originator Contact Phone Number

Fed Work Type

User Field

Reserved

M

M

M

M

M

M

M

M

C

C

C

C

C

C

M

01 - 02

03 - 04

05 - 13

14 - 22

23 - 30

31 - 38

39 - 42

43 - 43

44 - 44

45 - 52

53 - 66

67 - 76

77 - 77

78 - 79

80 - 80

2

2

9

9

8

8

4

1

1

8

14

10

1

2

1

N

N

N

N

N

N

N

A

AN

AN

ANS

N

AN

ANS

B

Note: All fields that are conditional and are not used shall be filled with banks.

Record Type


Note: This is a variable length record file. See annex F

for more information.

Usage

Position

Size

Type

Defined Values

Mandatory

01 - 02

2

N Numeric

‘10’ Cash letter header record


A code that identifies the type of cash letter. It will be set

to the same value as the collection type indicator (Field

2) in the bundle header record(s) (Type 20) in that cash

letter, if present and collection type indicator is not set to

defined value ‘99’. Bundles that do not carry value shall

not be mixed with other bundles that do carry value.

Bundles with defined values of ‘04’, ‘05’ or ‘06’ shall not

be mixed with bundles of other defined values in the

same cash letter.

Usage

Position

Size

Type

Defined Values

Mandatory

03 - 04

2

N Numeric

‘00’ Preliminary forward information – Used when

information may change and the information is

treated as not final.

‘01’ Forward presentment – For the collection and

settlement of checks (demand instruments). Data

are treated as final.

‘02’ Forward presentment – Same-day settlement –

For the collection and settlement of checks (demand

instruments) presented under the Federal Reserve’s

same day settlement amendments to regulation CC

(12CFR Part 229). Data are treated as final.

57

Defined Values ‘03’ Return – For the return of check(s). Transaction

carries value. Data are treated as final.

‘04’ Return notification – For the notification of

return of check(s). Transaction carries no value. The

return notification indicator (field 12) in the return

record (type 31) has to be interrogated to determine

whether a notice is a preliminary or final notification.

‘05’ Preliminary return notification – For the

notification of return of check(s). Transaction carries

no value. Used to indicate that an item may be

returned. This field supercedes the return notification

indicator (field 12) in the return record (type 31).

‘06’ Final return notification – For the notification of

return of check(s). Transaction carries no value. Used

to indicate that an item will be returned. This field

supercedes the return notification indicator (field 12)

in the return record (type 31).

Collection Type Indicator Continued

Defined Values

Continued

‘10’ Account totals – Used to report information at

the account level. Defined Value of the cash letter

record type indicator (field 8) shall be set to ‘N’.

‘20’ No detail – There are no detail records contained

within the bundle or cash letter. Defined value of the

cash letter record type (field 8) indicator shall be set

to ‘N’.

‘99’ Bundles not the same collection type.


A number that identifies the institution that receives and

processes the cash letter or the bundle.

Usage

Position

Size

Type

Format

Mandatory

05 - 13

9

N Numeric

TTTTAAAAC, where:

TTTT Federal Reserve prefix


C Check digit


A number that identifies the institution that creates the

cash letter header record.

Usage

Position

Size

Type

Format

Mandatory

14 - 22

9

N Numeric

TTTTAAAAC, where:



C Check digit

58

Cash Letter Business Date

The year, month, and day that designates the business

date of the cash letter.

Usage

Position

Size

Type

Format

Mandatory

23 - 30

8

N Numeric

YYYYMMDD, where:

YYYY year

MM month

DD day

Defined Values YYYY ‘1993’ through ‘9999’



Cash Letter Creation Date

The year, month, and day that the cash letter is created. Usage

Position

Size

Type

Defined Values

Mandatory

31 - 38

8

YYYYMMDD, where:

YYYY year

MM month

DD day

YYYY ‘1993’ through ‘9999’



Cash Letter Creation Time

The time the cash letter is created. If multiple files are

created simultaneously see field 11.

Usage

Position

Size

Type

Format

Defined Values

Mandatory

39 - 42

4

N Numeric

hhmm, where:

hh hour

mm minute

hh ‘00’ through ‘23’

mm ‘00’ through ‘59’

59

Cash Letter Record Type Indicator

A code that indicates the presence of records or the type

of records contained in the cash letter. If an image is

associated with any (even one) Check detail record (type

25), the cash letter must have a cash letter record type

indicator of defined value of ‘I’ or ‘F’.

Usage

Position

Size

Type

Defined Values

Mandatory

43 - 43

1

A Alphabetic

‘N’ No electronic check records or image records

(type 2x’s, 3x’s, 5x’s); e.g., Account totals only or an

empty cash letter.

‘E’ Cash letter contains electronic check records with

no images (type 2x’s and 3x’s only).

‘I’ Cash letter contains electronic check records (type

2x’s, 3x’s) and image records (type 5x’s).

Cash Letter Record Type Indicator Continued

‘F’ cash letter contains electronic check records

(type 2x’s and 3x’s) and image records (type 5x’s)

that correspond to a previously sent cash letter (e.g.

‘E’ file). The fields in this file that contain posting

data shall not be changed from the previously sent

cash letter with collection type indicator (field 2)

with defined values of ‘01’, ‘02’ or ’03. The items

within cash letter count (field 3) and cash letter total

amount (field 4) of the cash letter control record

(type 90) with a cash letter record type indicator of

cefined value of ‘F’ must equal the corresponding

fields in a cash letter with a cash letter record type

indicator of defined value of ‘E’.

Cash Letter Documentation Type Indicator

A code that indicates the type of documentation that

supports all check records in the cash letter. This code

indicates whether or not the items contained in the

cash letter are the same type. This field supersedes

the documentation type indicator (field 9) in the check

detail record (type 25) or the return documentation type

indicator (Field 8) in the return record (Type 31) for all

defined values except ‘Z’ not same type. In the case of

a defined value of ‘Z’ the documentation type indicator

(Field 9) in the check detail record type 25) or the return

documentation type indicator (field 8) in the return

record (type 31) takes precedent.

Usage Conditional

Shall be present when field 8 defined values equals

‘E’, ‘I’ or ‘F’.

Position

Size

Type

Defined Values

44 - 44

1

AN Alphameric

‘A’ No image provided, paper provided separately

‘B’ No image provided, paper provided separately ,

image upon request

‘C’ Image provided separately, no paper provided

‘D’ Image provided separately, no paper provided,

image upon request

60

‘E’ Image and paper provided separately

‘F’ Image and paper provided separately, image upon

request

‘G’ Image included, no paper provided

‘H’ Image included, no paper provided, image upon

request

‘I’ Image included, paper provided separately

‘J’ Image included, paper provided separately, image

upon request

‘K’ No image provided, no paper provided

‘L’ No image provided, no paper provided, image

upon request

‘M’ No image provided, Electronic check provided

separately

‘Z’ Not same type – Documentation associated with

each item in cash letter will be different. The check

detail record (type 25) as to be interrogated for

further information.

Cash Letter ID

A code that identifies the cash letter, assigned by the

institution that creates the cash letter.

Usage Conditional


arrangements.

Position

Size

Type

45 - 52

8

AN Alphameric

Originator Contact Name

A contact at the institution that creates the cash letter. Usage Conditional


arrangements.

Position

Size

Type

53 - 66

14

ANS Alphameric/special

Originator Contact Phone Number

The phone number of the contact at the institution that

creates the cash letter..

Usage Conditional

Shall be present if available, unless omitted under

clearing arrangements.

Position

Size

Type

67 - 76

10

N Numeric

61

Fed Work Type

A code that specifies the Federal Reserve work type. Usage Conditional

Shall be present only under clearing arrangements.

Position

Size

Type

Defined Values

77 - 77

1

AN Alphameric

‘1’ City

‘2’ City group

‘3’ City fine sort

‘4’ RCPC

‘5’ RCPC group

‘6’ RCPC fine sort

‘7’ High dollar group sort

‘8’ Country

‘9’ Country group sort

‘0’ Country fine sort

‘A’ Other district

‘B’ Other district group sort

Fed Work Type continued

Defined Values

continued

‘C’ Mixed

‘D’ City/RCPC mixed

‘E’ Payor group sort

User Field



arrangements.

Position

Size

Type

78 - 79

2


Reserved



Usage

Position

Size

Type

Mandatory

80 – 80

1

B Blank

62

Bundle Header Record (Type 20)The bundle header record is conditional and contains twelve fields. It shall be present when the cash letter record type indicator (field 8) in the cash letter header record (type 10) is not set to ‘N’. It always follows a cash letter header record (type 10) unless the cash letter contains multiple bundles then the bundle header record always follows a bundle control record (type 70), or a box summary record (type 75). The data in the fields are created by the ECE institution, which may or may not be the bank of first deposit (BOFD).


1

2

3

4

5

6

7

8

9

10

11

12

Record Type




Bundle Business Date

Bundle Creation Date

Bundle ID

Bundle Sequence Number

Cycle Number

Return Location Routing Number

User Field

Reserved

M

M

M

M

M

M

C

C

C

C

C

M

01 - 02

03 - 04

05 - 13

14 - 22

23 - 30

31 - 38

39 - 48

49 - 52

53 - 54

55 - 63

64 - 68

69 - 80

2

2

9

9

8

8

10

4

2

9

5

12

N

N

N

N

N

N

AN

NB

AN

N

ANS

B


Record Type



Usage

Position

Size

Type

Defined Values

Mandatory

01 - 02

2

N Numeric

‘20’ Bundle header record


A code that identifies the type of bundle. It shall be set to

the same value as the collection type indicator (Field 2) in

the cash letter header record (type 10) within which the

bundle is contained unless the collection type indicator

(field 2) in the cash letter header record (type 10) is set to

defined value ‘99’.

Usage

Position

Size

Type

Mandatory

03 - 04

2

N Numeric

Defined Values ‘00’ Preliminary forward information – Used when

information may change and the information is

treated as not final.

‘01’ Forward presentment – For the collection and

settlement of checks (demand instruments). Data are

treated as final.

‘02’ Forward presentment – Same-day settlement –

For the collection and settlement of checks (demand

instruments) presented under the Federal Reserve’s

same day settlement amendments to regulation CC

(12CFR Part 229). Data are treated as final.

63

‘03’ Return – For the return of check(s). Transaction

carries value. Data are treated as final.

‘04’ Return notification – For the notification of return

of check(s). Transaction carries no value. The return

notification indicator (field 12) in the return record

(type 31) has to be interrogated to determine whether

a notice is a preliminary or final notification.

‘05’ Preliminary return notification – For the

notification of return of check(s). Transaction carries

no value. Used to indicate that an item may be

returned. This field supercedes the return notification

indicator (field 12) in the return record (type 31).

‘06’ Final return notification – For the notification of

return of check(s). Transaction carries no value. Used

to indicate that an item will be returned. This field

supercedes the return notification indicator (field 12)

in the return record (type 31).


A number that identifies the institution that receives and

processes the cash letter or the bundle.

Usage

Position

Size

Type

Format

Mandatory

05 - 13

9

N Numeric

TTTTAAAAC, where:



C Check digit



bundle header record.

Usage

Position

Size

Type

Format

Mandatory

14 - 22

9

N Numeric

TTTTAAAAC, where:



C Check digit

64



date of the bundle.

Usage

Position

Size

Type

Format

Defined Values

Mandatory

23 - 30

8

N Numeric

YYYYMMDD, where:

YYYY year

MM month

DD day




Bundle Creation Date

The year, month, and day that the cash letter is created. Usage

Position

Size

Type

Format

Defined Values

Mandatory

31 - 38

8

N Numeric

YYYYMMDD, where:

YYYY year

MM month

DD day




Bundle ID

A number that identifies the bundle, assigned by the

institution that creates the bundle.

Usage Conditional


arrangements.

Position

Size

Type

39 - 48

10

AN Alphameric

Bundle Sequence Number

A number assigned by the institution that creates the

bundle. Usually denotes the relative position of the bundle

within the cash letter.

Usage Conditional


arrangements.

Position

Size

Type

49 - 52

4

NB Numericblank

65

Cycle Number

A code assigned by the institution that creates the

bundle. Denotes the cycle under which the bundle is

created.

Usage Conditional



Position

Size

Type

53 - 54

2

AN Alphameric

Return Location Routing Number

A routing number specified by the institution that creates

the bundle, indicating the location to which returns, final

return notifications and preliminary return notifications

should be sent.

Usage Conditional

Shall be present if collection type indicator value

is ‘01’ - forward presentment or ‘02’ - forward

presentment - same day settlement, unless omitted

under clearing arrangements.

Position

Size

Type

Format

55 - 63

9

N Numeric

TTTTAAAAC, where:



C Check digit

User Field



arrangements.

Position

Size

Type

64 - 68

5


Reserved

Usage

Position

Size

Type

Mandatory

69 - 80

12

B Blank

66

Check Detail Addendum C Record (Type 28)

The check detail addendum C record is conditional and contains eleven fields. It shall be present unless omitted under clearing arrangements. This record follows its immediately preceding check detail record (Type 25) or follows a check detail addendum A record (Type 26) or a check detail addendum B record (Type 27) if present. It is one of three addendum type records available for use with the check detail record (Type 25). Multiple check detail addendum C records are permitted for a check detail record (Type 25). Data in the check detail addendum C records are transferred to return addendum D records (Type 35) when the item is returned. This record is used for all previous forward or return electronic endorsements, except electronic BOFD endorsements that are carried on the check detail addendum A record (Type 26).


1

2

3

4

5

6

7

8

9

10

11

Record Type

Check Detail Addendum C Record Number

Endorsing Bank Routing Number

Endorsing Bank Endorsement Date

Endorsing Bank Item Sequence Number

Truncation Indicator

Endorsing Bank Conversion Indicator

Endorsing Bank Correction Indicator

Return Reason

User Field

Reserved

M

M

C

C

C

C

C

C

C

C

M

01 - 02

03 - 04

05 - 13

14 - 21

22 - 36

37 - 37

38 - 38

39 - 39

40 - 40

41 - 55

56 - 80

2

2

9

8

15

1

1

1

1

15

15

N

N

N

N

NB

A

AN

N

AN

ANS

B


Record Type



Usage

Position

Size

Type

Defined Values

Mandatory

01 – 02

2

N Numeric

‘28’ Check detail addendum C record

Check Detail Addendum C Record Number

This field shall contain the number representing the

chronological order in which each check detail addendum

C record was created. The order may not represent the

physical endorsement order. If the item becomes a return

this number is transferred to return addendum D record

Number (Type 35) return addendum D record number

(Field 2). The check detail addendum C records shall be

in sequential order according to this field.

Usage

Position

Size

Type

Mandatory

03 – 04

2

N Numeric

Endorsing Bank Routing Number

A number that identifies the bank that endorsed the

check.

Usage Conditional



67

Position

Size

Type

Format

05 – 13

9

N Numeric

TTTTAAAAC, where:



C Check digit

Endorsing Bank Endorsement Date

The year, month, and day in the endorsement that

designates the business date at the endorsing bank.

Usage Conditional



Position

Size

Type

Format

Defined Values

14 - 21

8

N Numeric

YYYYMMDD, where:

YYYY year

MM month

DD day




Endorsing Bank Item Sequence Number

A number that identifies the item at the endorsing bank. Usage Conditional



Position

Size

Type

22 - 36

15

NB Numericblank

Truncation Indicator

An indicator to identify if this endorsing institution is the

truncator of the original check.

Usage Conditional


arrangements.

Position

Size

Type

Defined Values

37 - 37

1

A Alphabetic

‘Y’ Yes this institution truncated the original check

‘N’ No this institution did not truncate the original

check

Endorsing Bank Conversion Indicator

A code that indicates the conversion within the

processing institution between original paper check,

image and IRD. The indicator is specific to the action of

this endorser.

Usage Conditional


arrangements.

68

Position

Size

Type

Defined Values

38 - 38

1

AN Alphameric

‘0’ Did not convert physical document

‘1’ Original paper converted to IRD

‘2’ Original paper converted to image

‘3’ IRD converted to another IRD

‘4’ IRD converted to image of IRD

‘5’ Image converted to an IRD

‘6’ Image converted to another image (e.g.

transcoded)

‘7’ Did not convert image (e.g. same as source)

‘8’ Undetermined

Endorsing Bank Correction Indicator

An indicator to identify whether and how the endorsing

bank repaired the MICR line.

Usage Conditional


arrangments.

Position

Size

Type

Defined Values

39 - 39

1

N Numeric

‘0’ No Repair

‘1’ Repaired

‘2’ Repaired without operator intervention

‘3’ Repaired with operator intervention

Return Reason

A code that indicates the reason for non-payment. Usage Conditional

Shall be present only when a return is being

represented electronically and the return reason was

included in the return record (Type 31).

Position

Size

Type

Defined Values

40 – 40

1

AN Alphameric

‘A’ NSF - Not sufficient funds

‘B’ UCF - Uncollected funds hold

‘C’ Stop payment

‘D’ Closed account

‘E’ UTLA - Unable to locate account

‘F’ Frozen/blocked account

‘G’ Stale dated

‘H’ Post dated

‘I’ Endorsement missing

‘J’ Endorsement irregular

‘K’ Signature(s) missing

‘L’ Signature(s) irregular

69

‘M’ Non-Cash item (non-negotiable)

‘N’ Altered/fictitious item

‘O’ Unable to process (e.g. mutilated item)

‘P’ Items exceeds dollar limit

‘Q’ Not authorized

‘R’ Branch/account sold (wrong bank)

‘S’ Refer to maker

‘T’ Stop payment suspect

‘U’ Unusable image (image could not be used for

required business purpose)

‘V’ Image fails security check

‘W’ Cannot determine amount

User Field



arrangements.

Position

Size

Type

41 – 55

15


Reserved



Usage

Position

Size

Type

Mandatory

56 - 80

15

B Blank

Image View Detail Record (Type 50)The image view detail record is conditional and contains seventeen fields. In a forward presentment bundle, this record follows its immediately preceding check detail record (Type 25) or follows a check detail addendum A re-cord (Type 26) or a check detail addendum B record (Type 27) or a check detail addendum C record (Type 28) if present. In a return bundle, this record follows its immediately preceding return record (Type 31) or follows a return addendum A record (Type 32) or a return addendum B record (Type 33) or a return addendum C record (Type 34) or a return addendum D record (Type 35) if present. The image view detail record shall also follow an Image view data record (Type 52) or an image view analysis record (Type 54) if present when an item has mul-tiple image views. The image view detail record shall be present if the cash letter record type indicator (Field 8) in the cash letter header record (Type 10) has defined values of ‘I’ or ‘F’. The image capture institution typically creates this record. The image view detail record is one of two records (Type 50 and Type 52) that shall be used together to convey an image view associated with the related check detail record (Type 25) or return record (Type 31). If an image view detail record is present, then an image view data record (type 52) shall be present.


1

2

3

4

5

6

Record Type

Image Indicator

Image Creator Routing Number

Image Creator Date

Image View Format Indicator

Image View Compression Algorithm Identifier

M

M

M

M

M

M

01 - 02

03 - 03

04 - 12

13 - 20

21 - 22

23 - 24

2

1

9

8

2

2

N

N

N

N

NB

NB

70


7

8

9

10

11

12

13

14

15

16

17

Image View Data Size

View Side Indicator

View Descriptor

Digital Signature Indicator

Digital Signature Method

Security Key Size

Start of Protected Data

Length of Protected Data

Image Recreate Indicator

User Field

Reserved

C

M

M

M

C

C

C

C

C

C

M

25 - 31

32 - 32

33 - 34

35 - 35

36 - 37

38 - 42

43 - 49

50 - 56

57 - 57

58 - 65

66 - 80

7

1

2

1

2

5

7

7

1

8

15

N

N

N

NB

N

N

N

N

N

ANS

B

Notes: All fields that are conditional and are not used shall be filled with blanks.

If the image indicator (field 2) has defined value of 0, the fields in this image view detail record shall have values as defined in normative annex E.

Record Type



Usage

Position

Size

Type

Defined Values

Mandatory

01 - 02

2

N Numeric

‘50’ Image view detail record

Image Indicator

A code that indicates the presence and disposition of

an image view conveyed in the related image view data

record (Type 52). When the image view is not available,

the fields in this image view detail record (Type 50) and

the related image view data record (Type 52) shall have

values as defined in normative annex E.

Usage

Position

Size

Type

Defined Values

Mandatory

03 - 03

1

N Numeric

‘0’ Image view not present

‘1’ Image view present, actual check

‘2’ Image view present, not actual check

‘3’ Image view present, unable to determine if defined

value is ‘1’ or ‘2’

Image Creator Routing Number

A number that identifies the financial institution that

created the image view in the related image view

data record (Type 52) image data (Field 19). [The

endorsement information conveyed in the applicable

addendum record provides an electronic endorsement

for the image creator.]

Usage

Position

Size

Type

Format

Mandatory

04 - 12

9

N Numeric

TTTTAAAAC, where:


AAAA ABA Institution identifier

C Check digit

71

Image Creator Date

Date assigned by the image creator for the image view

conveyed in the related image view data record (type 52)

image data (field 19).

Usage

Position

Size

Type

Format

Mandatory

13 - 20

8

N Numeric

YYYYMMDD, where:

YYYY year

MM month

DD day




Image View Format Indicator

A code that identifies the type of image format used in

the related Image view data record (type 52) image data

(field 19). Values ‘0’ through ‘19’ may be used without a

pre-existing agreement. Values ‘20’ through ‘99’ shall only

be used when an agreement exists indicating that sender

and receiver both support the specified image format

type and the type is specified below or on the X9 website.

The image format type is also commonly specified by

reference to the file extension used when image data is

saved as an image file. The file extension for each image

format is included below for reference.

Usage

Position

Size

Type

Defined Values

Mandatory

21 - 22

2

N Numeric

Agreement not required:

‘0’ TIFF 6; Extension: TIF

‘1’ IOCA FS 11; Extension: ICA

‘2’ through ’19 Reserved (agreement is not required)

Agreement required:

‘20’ PNG (Portable Network Graphics); Extension:

PNG

‘21’ JFIF (JPEG File Interchange Format); Extension:

JPG

‘22’ SPIFF (Still Picture Interchange File Format)

(ITU-T Rec. T.84 Annex F); Extension: SPF

‘23’ JBIG data stream (ITU -T Rec. T.82/ISO/IEC

11544:1993); Extension: JBG

‘24’ JPEG 2000 (ISO/IEC 15444-1:2000); Extension:

JP2

‘25’ through ‘99’ Reserved for image format and

encapsulation technologies as defined on the

X9 website (www.X9.org). Only supported under

agreement.

72

Image View Compression Algorithm Identifier

A code that identifies the algorithm or method used to

compress the image data in the related image view data

record (type 52) image data (field 19). Values ‘0’ through

‘20’ may be used without a pre-existing agreement.

Values ‘21’ through ‘99’ shall only be used when an

agreement exists indicating that sender and receiver both

support the specified image compression method and

the method is specified below or on the X9 website.

Usage

Position

Size

Type

Defined Values

Mandatory

23 - 24

2

N Numeric

Agreement not required:

‘0’ Group 4 facsimile compression (ITU-T Rec. T.563/

CCITT Rec. T.6)

‘1’ JPEG Baseline (JPEG Interchange Format)(ITU-T

Rec. T.81/ISO/IEC 10918)

‘2’ ABIC

‘3’ through ’20 Reserved (agreement is not required)

Image View Data Size continued

Agreement required:

‘21’ PNG (Portable Network Graphics)

‘22’ JBIG (ITU -T Rec. T.82/ISO/IEC 11544:1993)

‘23’ JPEG 2000 (ISO/IEC 15444-1:2000)

‘24’ through ‘99’ Reserved for emerging image

compression technologies as defined on the X9

website. (www.X9.org). Only supported under

agreement.

Image View Data Size

The total number of bytes in the related image view data

record (type 52) image data (field 19). This field has the

same value as the length of image data (field 18) in the

corresponding image view data record (type 52). If image

view data size is greater than 9,999,999 then image

indicator defined value shall equal ‘0.

Usage Conditional


arrangements.

Position

Size

Type

Defined Values

25 - 31

7

N Numeric

‘1’ through ‘9999999’

View Side Indicator

A code that indicates the image view conveyed in the

related image view data record (type 52) image data

(field 19). An image view may be a full view of the item

(e.g., the entire full face of the document) or may be a

partial view (snippet) as determined by the value of the

view descriptor field (field 9).

Usage

Position

Size

Type

Defined Values

Mandatory

32 - 32

1

N Numeric

‘0’ Front image view

‘1’ Rear image view

73

View Descriptor

A code that indicates the nature of the image view

conveyed by the image data (field 19) in the image view

data record (type 52).

Usage

Position

Size

Type

Defined Values

Mandatory

33 - 34

2

N Numeric

‘‘0’ Full view

‘1’ Partial view – unspecified area of interest

‘2’ Partial view – date area of interest

‘3’ Partial view – payee area of interest

‘4’ Partial view – convenience amount area of interest

‘6’ Partial view – signature area(s) of interest

‘7’ Partial view – payor name and address area of

interest

‘5’ Partial view – amount in words (legal amount) area

of interest

‘8’ Partial view – MICR line area of interest

‘9’ Partial view – memo line area of interest

‘10’ Partial view – payor bank name and address Area

of Interest

‘11’ Partial view – payee endorsement area of interest

‘12’ Partial view – Bank Of First Deposit (BOFD)

endorsement area of interest

‘13’ Partial view – transit endorsement area of interest

‘14’ through ‘99’ reserved for X9

Digital Signature Indicator

A code that indicates the presence or absence of a digital

signature for the image view contained in the related

Image view data record (type 52) image data (field 19).

If present, the digital signature is conveyed in the related

image view data record (type 52) digital signature (field

17).

Usage

Position

Size

Type

Defined Values

Mandatory

35 - 35

1

N Numeric

‘0’ Digital signature is not present

‘1’ Digital signature is present

74

Digital Signature Method

A code that identifies the cryptographic algorithm used to

generate and validate the digital signature in the related

image view data record (type 52) digital signature (field

17).

Usage Conditional

Shall be present if field 10 in this image view detail

record has defined value of 1.

Position

Size

Type

Defined Values

36 - 37

2

N Numeric

‘0’ Digital Signature Algorithm (DSA) with SHA1

(ANSI X9.30)

‘1’ RSA with MD5 (ANSI X9.31)

‘2’ RSA with MDC2 (ANSI X9.31)

‘3’ RSA with SHA1 (ANSI X9.31)

‘4’ Elliptic Curve DSA (ECDSA) with SHAI (ANSI

X9.62)

‘5’ through ‘99’ Reserved for emerging cryptographic

algorithms and technologies as defined on the X9

website. (www.X9.org).

Security Key Size

The length in bits of the cryptographic algorithm key used

to create the digital signature in the related image view

data record (type 52) digital signature (field 17).

Usage Conditional

Shall be present only under clearing arrangements

and when field 10 in this image view detail record has

defined value of 1.

Position

Size

Type

Defined Values

38 - 42

5

N Numeric

‘1’ through ‘99999’

Start of Protected Data

A number that represents the offset in bytes from the first

byte (counted as byte 1) of the image data in the related

image view data record (type 52) image data (field 19) to

the first byte of the image data protected by the digital

signature.

Usage Conditional



Position

Size

Type

Defined Values

43 - 49

7

N Numeric

‘0’ Digital signature is applied to the entire image data

‘1’ through ‘9999999’ valid offset values

Length of Protected Data

The number of contiguous bytes of image data in the

related Image view data record (type 52) image data

(field 19) protected by the digital signature starting with

the byte indicated by the value of the start of protected

data in this image view detail record. The length of

protected data value shall not exceed the length of image

data (field 18) value in the corresponding image view data

record (type 52).

Usage Conditional



Position

Size

Type

Defined Values

50 - 56

7

N Numeric

‘0’ Digital signature is applied to entire image data

‘1’ through ‘9999999’ valid length values

75

Image Recreate Indicator

A code that indicates whether the sender has the ability

to recreate the image view conveyed in the related image

view data record (type 52) image data (field 19).

Usage Conditional


arrangements

Position

Size

Type

Defined Values

57 - 57

1

N Numeric

‘0’ Sender can recreate the image view for the

duration of the agreed to retention timeframes.

‘1’ Sender cannot recreate image view.

User Field


Shall be present only under certain clearing

arrangements.

Position

Size

Type

58 - 65

8


Reserved



Usage

Position

Size

Type

Mandatory

66 - 80

15

B Blank

Image View Data Record (Type 52)The image view data record is conditional and contains nineteen fields. This record follows its immediately pre-ceding Image view detail record (type 50). The image view data record shall be present if the cash letter type indicator (field 8) in the cash letter header record (type 10) has defined value of ‘I’ or ‘F’. Sixteen of the nineteen fields are fixed length and three are variable length. The image capture institution typically creates this record. The image view data record is one of two records (type 50 and type 52) that shall be used together to convey an image view associated with the related check detail record (type 25) or return record (type 31). If an image view detail record (type 50) is present, then an image view data record shall be present.


1

2

3

4

5

Record Type

Item Reference Key

ECE Institution Routing Number (Clause 9.4)

Bundle Business Date (Clause 9.5)

Cycle Number (Clause 9.9)

ECE Institution Item Sequence Number (Clause 10.8)

M

M

M

C

M

01 - 02

03 - 11

12 - 19

20 - 21

22 - 36

2

9

8

2

15

N

N

N

AN

NB

76

6

7

8

Additional Security Information

Security Originator Name

Security Authenticator Name

Security Key Name

C

C

C

37 - 52

53 - 68

69 - 84

16

16

16

ANS

ANS

ANS

9

10

11

12

13

Clipping Information

Clipping Origin

Clipping Coordinate h1


Clipping Coordinate v1

Clipping Coordinate v2

M

C

C

C

C

85 - 85

86 - 89

90 - 93

94 - 97

98 - 101

1

4

4

4

4

NB

N

N

N

N

14

15

Image Reference Key

Length of Image Reference Key

Image Reference Key

M

C

102 - 105

106 - (105+x)

4

Variable (X)

NB

ANS

16

17

18

19

Binary Data Information

Length of Digital Signature

Digital Signature

Length of Image Data

Image Data

M

C

M

M

(106+X) – (110+X)

(111+X) –

(110+X+Y)

(111+X+Y) –

(117+X+Y)

(118+X+Y) –

(117+X+Y+Z)

5

Variable (Y)

7

Variable (Z)

NB

Binary

NB

Binary

Notes: Fixed length fields that are conditional and are not used shall be filled with blanks. Variable length fields that are not used (e.g. Size = 0) are omitted. If the image indicator (field 2) in the related image view detail record (type 50) has value = 0, the fields in this image view detail record shall have values as defined in normative annex E.

Record Type



Usage

Position

Size

Type

Defined Values

Mandatory

01 - 02

2

N Numeric

‘52’ Image view data record



bundle header record. This number is imported from the

bundle header record (clause 9.4) associated with the

image view conveyed in this image view data record.

Usage

Position

Size

Type

Mandatory

03 - 11

9

N Numeric

77



date of the bundle. This number is imported from the

bundle header record (clause 9.5) associated with the

image view conveyed in this image view data record.

Usage

Position

Size

Type

Format

Mandatory

12 - 19

8

N Numeric

YYYYMMDD, where:

YYYY year

MM month

DD day




Cycle Number

A code assigned by the institution that creates the

bundle. Denotes the cycle under which the bundle is

created. This number is imported from the bundle header

record (clause 9.9) associated with the image view

conveyed in this image view data record.

Usage Conditional



Position

Size

Type

20 - 21

2

AN Alphameric

ECE Institution Item Sequence Number

A number assigned by the institution that creates the

check detail record (type 25). This number is imported

from the check detail record (clause 10.8) associated with

the image view conveyed in this image view data record.

The ECE institution must construct the sequence number

to guarantee uniqueness for a given routing number,

business day, and cycle number.

Usage

Position

Size

Type

Mandatory

22 - 36

15

NB Numeric blank

Security Originator Name

Unique designation of the entity that creates the digital

signature for data to be exchanged.

Usage Conditional


and when field 10 in the related Image view detail

record (type 50) has defined value of 1.

Position

Size

Type

37 - 52

16


Security Authenticator Name

Unique designation of the entity that performs

authentication on received data.

Usage Conditional


and when field 10 in the related image view detail


Position

Size

Type

53 - 68

16


78

Security Key Name

A name or character sequence used by the signer

(originator) to communicate a key identifier to the

recipient (authenticator) so the recipient can obtain

the key needed to validate the signature. The name is

typically used as an identifier related to the key pair used

to sign the image. The name is mutually known to the

security originator and the security authenticator and is

unique to this relationship.

Usage Conditional


and when field 10 in the related image view detail


Position

Size

Type

69 - 84

16


Clipping Origin

A code that defines the corner of the conveyed image

view that is taken as the reference point for the clipping

coordinates. Top, bottom, left, and right references apply

to a view that presents a visually correct orientation.

When clipping information is present, the nature of

the area of interest defined by the clipping rectangle is

determined by the value of the view descriptor (field 9) in

the related image view detail record (type 50).

Usage

Position

Size

Type

Defined Values

Mandatory

85 - 85

1

N Numeric

‘0’ Clipping information is not present

‘1’ Clipping origin is top left corner of image view

‘2’ Clipping origin is top right corner of image view

‘3’ Clipping origin is bottom right corner of image

view

‘4’ Clipping origin is bottom left corner of image view


A number that represents the horizontal offset in pixels

from the clipping origin to the nearest vertical side of

the clipping rectangle. The clipping coordinates (h1, h2,

v1, v2) convey the clipping rectangle’s offsets in both

horizontal (h) and vertical (v) directions. The offset

values collectively establish the bounding sides of the

clipping rectangle. Pixels on the boundary of the clipping

rectangle are included in the selected array of pixels. That

is, the first pixel of the selected array is at offset (h1, v1)

and the last pixel of the selected array is at offset (h2,

v2). The corner pixel at the origin of the image view is

assumed to have the offset value (0, 0).

Usage Conditional

Shall be present if clipping origin (field 9) in this

image view data record is non-zero.

Position

Size

Type

Defined Values

86 - 89

4

N Numeric

‘0’ through ‘9999’

Clipping Coordinates h2

A number that represents the horizontal offset in pixels

from the clipping origin to the furthermost vertical side of

the clipping rectangle.

Usage Conditional



Position

Size

Type

Defined Values

90 – 93

4

N Numeric

‘0’ through ‘9999’

79

Clipping Coordinates v1

A number that represents the vertical offset in pixels from

the clipping origin to the nearest horizontal side of the

clipping rectangle.

Usage Conditional



Position

Size

Type

Defined Values

94 – 97

4

N Numeric

‘0’ through ‘9999’

Clipping Coordinates v2

A number that represents the vertical offset in pixels from

the clipping origin to the furthermost horizontal side of

the clipping rectangle.

Usage Conditional



Position

Size

Type

Defined Values

98 – 101

4

N Numeric

‘0’ through ‘9999’

Length of Image Reference Key

The number of characters in the image reference key

(field 15) in this image view data record.

Usage

Position

Size

Type

Defined Values

Mandatory

102 – 105

4

N Numeric

‘0’ Image reference key (field 15) is not present

‘1’ through ‘9999’ valid when image reference key

(field 15) is present

Image Reference Key

A designator assigned by the ECE institution that creates

the check detail, return and image view records. This

designator, when used, should uniquely identify the item

image to the ECE institution. This designator could be

a key that would be used by the creating institution to

locate the unique associated image or it could provide a

full access path and name that would allow direct external

look up and access of the image. For example, this could

be a URL. This field would normally match image archive

sequence number/image archive locator (field 5) in the

check detail addendum B record (type 27), or return

addendum C record (type 34), if used. See annex I for

more information in developing the Image Key.

Usage Conditional

Shall be present if the Item reference key consisting

of fields 2 – 5 is not unique and length of image

reference key (field 14) in this image view data record

has a value of non-zero

Position

Size

Type

variable (see table)

‘1’ through ‘9999’


Length of Digital Signature

The number of bytes in the digital signature field (field 17)

in this image view data record.

Usage

Position

Size

Type

Defined Values

Mandatory

Variable (see table)

5

NB Numeric blank

‘0’ Digital signature field is not present

‘1’ through ‘99999’ (valid when digital signature field

is present)

80

Digital Signature

The digital signature created by applying the

cryptographic algorithm and private/secret key against

the data to be protected. The digital signature provides

user authentication and data integrity.

Usage Conditional

Shall be present if digital signature indicator (field 10)

in the related image view detail record (type 50) has

defined value of 1.

Position

Size

Type


‘1’ through ‘99999’

Binary

Length of Image Data

The number of bytes in the image data (field 19) in this

image view data record.

Usage

Position

Size

Type

Defined Values

Mandatory


7

NB Numeric blank

‘1’ through ‘9999999’

Image Data

The image data field contains the image view. The image

data generally consists of an image header and the image

raster data. The image header provides information

that is required to interpret the image raster data. The

image raster data contains the scanned image of the

physical item in raster (line by line) format. Each scan

line comprises a set of concatenated pixels. The image

comprises a set of scan lines. The image raster data is

typically compressed to reduce the number of bytes

needed to transmit and store the image. The header/

image format type is defined by the image view format

indicator (field 5) in the corresponding image view detail

record (type 50). The syntax and semantics of the image

header/image format are understood by referring to the

appropriate image format specification. The compression

scheme used to compress the image raster data is

specified in the image view compression algorithm

identifier (field 6) of the associated image view detail

record (type 50), and in the image header portion of the

image data or by association with the selected image

format.

Usage

Position

Size

Type

Mandatory

variable (see table)

‘1’ through ‘9999999’

Binary

81

Bundle Control Record (Type 70)The bundle control record is conditional, and contains seven fields. It shall be present to complete a bundle that began with a bundle header record (Type 20). There shall be one bundle control record corresponding to each bundle header record (type 20). This record shall always follow one of the following records: check detail record (type 25) or check detail addendum A record (type 26) or check detail addendum B record (type 27) or check detail addendum C record (type 28) or return record (type 31) or return addendum A record (type 32) or return addendum B record (type 33) or return addendum C record (type 34) or return addendum D record (type 35) or image view data record (type 52 or image view analysis record (type 54). It shall be the last record of the bundle. The data in the fields are generated by the ECE institution that created the corresponding bundle header record.


1

2

3

4

5

6

7

Record Type

Items Within Bundle Count

Bundle Total Amount

MICR Valid Total Amount

Images within Bundle Count

User Field

Reserved

M

M

M

C

C

C

M

01 - 02

03 - 06

07 - 18

19 - 30

31 - 35

36 - 55

56 - 80

2

4

12

12

5

20

25

N

N

N

N

N

ANS

B


Record Type



Usage

Position

Size

Type

Defined Values

Mandatory

01 - 02

2

N Numeric

‘70’ Bundle control record

Items Within Bundle Count

The total number of items sent within a bundle, all check

detail records (type 25) or all return records (Type 31).

Usage

Position

Size

Type

Mandatory

03 - 06

4

N Numeric

Bundle Total Amount

The total US dollar value of the items within the bundle,

all check detail records (type 25) or all return records

(type 31).

Usage

Position

Size

Type

Mandatory

07 - 18

12

N Numeric

MICR Valid Total Amount

The total US dollar value of all check detail records (type

25) which contain the defined value ‘1’ in the MICR valid

indicator (field 11).

Usage Conditional


Position

Size

Type

19 - 30

12

N Numeric

82

Images Within Bundle Count

The total number of image views within a bundle. Each

image is represented by an image view detail record (type

50) and an image view data record (type 52) pair.

Usage Conditional


Position

Size

Type

31 - 35

5

N Numeric

User Field



Position

Size

Type

36 - 55

20


Reserved



Usage

Position

Size

Type

Mandatory

56 - 80

25

B Blank

Cash Letter Control Record (Type 90)The cash letter control record is mandatory and contains eight fields. There must be one cash letter control record corresponding to each cash letter header record (type 10) and shall be the last record in the cash letter. It shall always follow a bundle header record (type 70) or a box summary record (type 75) or a routing number summary record (type 85), if present. The data in the fields are generated by the ECE institution that created the corresponding cash letter header record.


1

2

3

4

5

6

7

8

Record Type

Bundle Count

Items Within Cash letter Count

Cash Letter Total Amount

Images Within Cash Letter Count

ECE Institution Name

Settlement Date

Reserved

M

M

M

M

C

C

C

M

01 - 02

03 - 08

09 - 16

17 - 30

31 - 39

40 - 57

58 - 65

66 - 80

2

6

8

14

9

18

8

15

N

N

N

N

A

A

N

B


Record Type



Usage

Position

Size

Type

Defined Values

Mandatory

01 - 02

2

N Numeric

‘90’ Cash letter control record

83

Bundle Count

The total number of bundles within the cash letter. Usage

Position

Size

Type

Mandatory

03 - 08

6

N Numeric

Items Within Cash Letter Count

The total number of items sent within the cash letter, all

check detail records (Type 25) or all return records (type

31).

Usage

Position

Size

Type

Mandatory

09 - 16

8

N Numeric

Cash Letter Total Amount

The total US dollar value of the cash letter, all check detail

records (type 25) or all return records (type 31).

Usage

Position

Size

Type

Mandatory

17 - 30

14

N Numeric

Images Within Cash Letter Count

The total number of image views within a cash letter.

Each image is represented by an image view detail record

(type 50) and an image view data record (type 52) pair.

Usage Conditional


arrangementsPosition

Size

Type

31 - 39

9

N Numeric

ECE Institution Name

The short name of the institution that creates the cash

letter control record (Type 90).

Usage Conditional


arrangements.

Position

Size

Type

40 - 57

18

A Alphabetic

Settlement Date

The year, month, and day that the institution that creates

the cash letter expects settlement.

Usage Conditional


arrangements.

Position

Size

Type

58 - 65

8

N Numeric

84

Format

Defined Values

YYYYMMDD, where:

YYYY year

MM month

DD day

YYYY‘1993’ through ‘9999’



Reserved



Usage

Position

Size

Type

Mandatory

66 - 80

15

B Blank

File Control Record (Type 99)The file control record is mandatory and contains eight fields. It is the final record of an electronic check exchange file. It shall always follow a cash letter control record (type 90). The data in the fields are created by the institution sending the file, the immediate origin institution.


1

2

3

4

5

6

7

8

Record Type

Cash Letter Count

Total Record Count

Total Item Count

File Total Amount

Immediate Origin Contact Name

Immediate Origin Contact Phone Number

Reserved

M

M

M

M

M

C

C

M

01 - 02

03 - 08

09 - 16

17 - 24

25 - 40

41 - 54

55 - 64

65 - 80

2

6

8

8

16

14

10

16

N

N

N

N

N

ANS

N

B


Record Type



Usage

Position

Size

Type

Defined Values

Mandatory

01 - 02

2

N Numeric

‘99’ File control record

Cash Letter Count

The total number of cash letters within the file. Usage

Position

Size

Type

Mandatory

03 - 08

6

N Numeric

85

Total Record Count

The total number of records of all types sent in the file,

including the file control record.

Usage

Position

Size

Type

Mandatory

09 - 16

8

N Numeric

Total Item Count

The total number of items sent within the file, all check

detail records (Type 25) and all return records (type 31)..

Usage

Position

Size

Type

Mandatory

17 - 24

8

N Numeric

File Total Amount

The total US dollar value of the complete file, all check

detail records (Type 25) and all return records (type 31).

Usage

Position

Size

Type

Mandatory

25 - 40

16

N Numeric

Immediate Origin Contact Name

A contact at the institution that creates the ECE file. Usage Conditional


arrangements.

Position

Size

Type

41 - 54

14


Immediate Origin Contact Phone Number

The phone number of the contact at the institution that

creates the file.

Usage Conditional


arrangements.

Position

Size

Type

55 - 64

10

N Numeric

Reserved



Usage

Position

Size

Type

Mandatory

65 - 80

16

B Blank

86

Integrated PayablesIntegrated Payables is a payments outsourcing service that provides check print and mail and electronic payment processing options. Integrated Payables enables your company to make the transition from printing and mailing checks with remittances to electronic payments with electronic remittance delivery, without requiring changes to your existing A/P process.

Upload File SpecificationsAlthough Integrated Payables has the ability to work with many different file formats, certain data elements are required to be included in the file uploaded to Integrated Payables in order to process your payments.

Data Element Name Element Type Max Length Required Type

Recipient_Name string 100 Y The full name of the recipient, e.g. John Smith Jr.

Recipient_Address1 string 70 N Standard address data





Recipient_ID_Num string 50 Y The ID by which the payer uniquely identifies the payee

internally or in its software systems.

Contact1_Name string 100 Y Name of person who can validate account information

during registration process.

Contact1_Phone string 20 Y Telephone number of person who can validate account

information during registration process.

Contact1_Email string 100 Y Email address of person who can validate account


Contact2_Name string 100 N Name of alternate person who can validate account


Contact2_Phone string 20 N Telephone number of alternate person who can validate

account information during registration process.

Contact2_Email string 100 N Email address of alternate person who can validate

account information during registration process.

Payer Identification

Number

string 50 N Optional data field that uniquely identifes the payer in

the payee’s software system (e.g. customer number

or account number with the payee). This would be

a required field for payers with multiple subsidiary

companies.

• The address lines should be specified as if they were used to address an envelope. ie, attention line(s), then street address line(s), then the city, state, and ZIP code, then country.

• The city, state and ZIP must be provided in one line. ex Birmingham, AL 35233

• If a country is to be provided it must be alone, as the last address line to be specified.

• Other data elements may be passed, they will be stored in an overflow field in the database.

Transmission MethodsYou can transmit your files to us using one of the two transmission protocols listed below:

• FTPS (also known as FTP Secure and FTP-SSL) including the use of server-side public key authentication certificates and client-side authorization certificates.

• SFTP (also known as SSH File Transfer Protocol or Secure File Transfer Protocol) including the use of public/private keys and/or passwords.

Files can be encrypted with PGP. We use a PGP 9.0 key, so you will need a licensed copy of 9.0 to import our key.

87

For SFTP communications, authentication can be achieved in one of the three ways listed below:

• Password authentication: Client uses the provided username and password to authenticate and upload files

• Public key authentication: Client creates a private/public key pair and provides us the public key. The public key is imported into the client account allowing the client to skip the password.

• This requires a compatible SFTP program that allows the import of a private key

• It is the client’s responsibility to create and send the appropriate public key

• It is the clients responsibility to acquire a compatible SFTP program

• Password and public key authentication: this is a combination of both methods. It is the most secure and bank recommended method of SFTP authentication

For FTPS communications:

• BBVA will provide the certificate chain in a zip file

• Your company is responsible for importing the certificates following the appropriate instructions for the operating system used; BBVA cannot be responsible for providing these instructions

File Validation and DeletionIntegrated Payables is designed to work with approved payment files. The file structure is validated each time a file is submitted. If the file structure is not correct the file will not load and you will be notified immediately. BBVA will work with you to identify the error so you can correct the error and resubmit the payment file for processing.

Using the secure website you will have the ability to upload files to be held, deleted, and reviewed by an authorized user. Once files are submitted into production you will have the ability to call or email your local Business Relationship Services representative requesting the file be cancelled any time before the processing and/or printing begins.

Loan StatementsCustomers who have loans with BBVA can download a copy of their loan statement through the BBVA Net Cash electronic report delivery module. Shown below is a sample of the report:

88

Loan Balances and TransactionsYou can export a file of your current loan balances plus transactions for a specified date range from BBVA Net Cash. Shown below is a sample loan report exported in comma-delimited (CSV) format:

89

LockboxCustomers using BBVA’s lockbox services have several options for receiving their data and images and transmitting their stop/accept files.

LRA CD or DVDEach time you receive a Lockbox Remittance Archive (LRA) CD or DVD, you will be required to enter a pass phrase during the import process before the data and images can be copied onto your respective PC or network. There is a security application in addition to the image viewer application that must be installed to your PC or network to view the lockbox data and images. Please read the LRA user guide for detailed instructions on how to install the applications and export the data and images from the CD or DVD.

Image File & Quick PrintAs an alternative to receiving files by CD/DVD each month, you may elect to receive transaction data and images using BBVA’s File Transfer Services. These image files are provided daily, and can be viewed using the same LRA viewer used to view images on CD-ROM. Please read the LRA user guide for detailed instructions on how to download the files from our File Transfer Services site.

Sometimes referred to as Quick Print, this image file will contain your daily package. It enables you to receive images within a single output so they can quickly print your checks, documents and daily reports. Images are available the same day based on your established deposit cutoff. It also contains a simple search utility so you can easily locate your desired output files.

Tip: Be sure you review the earlier section in this guide for File Transfer Services to verify that your systems are compatible with this solution.

BBVA Net Cash ReportingThe BBVA Net Cash Lockbox Reporting Service allows you to view either summary or detail reports of lockbox transactions processed over the past 120 calendar days, 2 years or 3 years based on your subscription. From the detail reports, you can view images of checks and related documents associated with each transaction period. Please refer to the online help resource, as well as the lockbox video tutorial accessible in the reference center for guidance on how to set up and view reports.

Data can be downloaded in CSV format. Images of checks and documents can be viewed individually and downloaded in PDF format. The PDF will contain images of all the checks and documents associated with a particular batch transaction. It is not a comprehensive download of all the items within your daily package.

Accounts Receivable Invoice MatchingAccounts Receivable Invoice Matching is the fastest and most efficient way to improve your auto cash posting results. Traditional lockbox processing allows for only a portion of your receivables to close based on the information in your overnight data transmission file. To gain new efficiencies, BBVA can match open receivables to the information captured from your BBVA lockbox. You have the option to view exceptions online and repair unmatched items, facilitating a balanced, auto-postable file for straight-through processing. Alternatively, BBVA can send a file and flag unmatched receivables for research the following day. With either service, you can redirect FTE you have posting receivables, eliminating the manual processing of clean payments.

Requirements:

• Records must be sorted in numeric order.

• Records smaller than the defined field should be left padded with spaces

• The first field name should be the primary lookup field to match

• Field names will be confirmed with the lockbox department at time of set up

90

Record Code Record Name Descriptions

1 Date in YYYY.MM.DD format 2015.02.23

2 Bank will provide this information BHM986802AR

3 Field names and start/end position inv,1,6

acct,8,11

amt,13,18

4 Number of records 8

5 Records 24875 3156 71.00

87318 6879 100.00

97610 7984 30.00

97611 7984 30.00

97612 7984 30.00

98731 9812 250.00

458128 6587 50.00

861042 6587 100.00

6 EOF indicator EOF

Custom FormatData can be customized to your specific needs to automate back office A/R posting. Please contact your treasury management officer for details, as this will require additional testing and set up.

Tip: Custom formats must be transmitted using BBVA e-Transmit or File Transfer Services These files cannot be downloaded from BBVA Net Cash. Image files are limited to File Transfer Services.

Stop/Accept File Processing Specifications

Stop/Accept Files

Stop Files Accept Files

Stop files allow the automatic rejection of a transaction based on details of the transaction.

Accept files allow the automatic acceptance of a transaction based on details of the transaction.

For a stop file, you supply a file containing a list of account numbers which should be rejected. This is known as a ‘negative stop file’, where the accounts defined in the stop file are rejected.

For an accept file, you supply a file containing a list of account numbers which should be accepted. This is known as a ‘positive stop file’, where only account numbers in the file are allowed and others are rejected.

In both of these cases, each record in the stop file typically contains a ‘CustNumber’ field which represents an account number. The ‘CustNumber’ field defines a value which is compared to a keyed field and therefore may represent any piece of data keyed from the transaction (not just an account number).

It is also possible for the stop file to identity a transaction based on the routing transit number and deposit account number from the check MICR line.

Stop/Accept File Import Formats

The files must be in a CSV Format with a header record. Header record needs to be XXX-###### where X=the lockbox site and #=lockbox number. Both will be provided by the bank at the time of implementation.

91

As an example, the following might be a file containing the header and two records:

XXX-######

16529991,20080509,ACC

92743921,20080610,DNP

The names of the files (stop or accept) can be anything up to 23 characters with the dot extension, but they must begin with “STOP”.

After the header line, each line of the file represents a single ‘Stop File Record’ or ‘Accept File Record’. Each line may define one or more of the fields shown in the table below. Some of the field names have alternatives (for example the ‘CustNumber column may also be called the ‘Account’ field).

CustNumber or Account The customer identification value to be compared to the keyed

Transit A routing transit number to be compared to the MICR line Routing Transit number

DDA An account number to be compared to the MICR line account number

MinAmount A dollar/cent amount, the ‘.’ is optional

MaxAmount A dollar/cent amount, the ‘.’ is optional

LateDate A date in the format YYYYMMDD

FinalDate A date in the format YYYYMMDD

Stop/AcceptCode A DNP code for a stop. An ACC code for an accept file

Each line of the file must specify a unique key value which may be:

CustNumber or Account The keyed field is compared against this value and, if it matches, this record is used in stop or accept file processing.

Transit and DDA The values are compared against the routing transit and account number from the check MICR line and, if they both match, this record is used in stop or accept file processing.

If neither a ‘CustNumber’ (or ‘Account’) field nor the ‘Transit’ and ‘DDA’ fields are specified in the import file, the line is discarded.

Note: It is allowable for a stop file to contain reject codes for some records and accept codes for others.

92

Received ACH Transactions (NACHA Format)BBVA can deliver files containing ACH transactions that you received to your account in NACHA Format through File Transfer Services. All NACHA formats (e.g. CCD, CCD+, CTX, IAT etc.) are supported. The formats used depend on what the originator of the transaction sends to your account.

The file sent to you is a NACHA fixed record length format and includes Record 1 (File Header), Record 5 (Batch Header), Record 6 (Transaction), Record 7 (Addenda - which is generally in ASC X.12 version 5010), Record 8 (Batch Footer), and Record 9 (File footer).

An example of the file that you will receive is shown below:

93

Sweep StatementsCustomers who use the Goldman-Sachs Mutual Funds through BBVA also have the ability to download their shareholder statement through the BBVA Net Cash Electronic Reports Service. Shown below is a sample of the report:

94

Wire Transfer ReportingThe following information details the format of the BAI2 file you will receive as a part of the wire transfer reporting service.

Record Code and Type DescriptionsThe following section outlines the required record codes standard of a BAI2 file format. Record codes define the record’s purpose within the BAI2 file. BAI2 record codes and their descriptions are provided in the table below.

Record Code Record Name Descriptions

01 File Header Indicates the beginning of the file and structure of the file

02 Group Header Identifies a group of accounts with the same originator, as-of-date and as-of-time

03 Account Identifier Identifies the beginning of an account

16 Transaction Detail Holds the detailed transaction information about the account represented

in the “03” record

88 Continuation Record Used when a record exceeds the maximum physical record length; text field

49 Account Trailer Identifies the end of an account and provides account totals

98 Group Trailer Identifies the end of a group of accounts; provides group control totals

99 File Trailer Indicates the end of the file and provides file control totals

Record types are three-digit codes used to identify the types of transactional activity occurring within the specified account.

Record Code Descriptions

195 Incoming Money Transfer

196 Money Transfer Adjustment – Credit [1]

206 Book Transfer Credit

208 Individual International Money Transfer Credits

216 Foreign Transfer Credit

495 Outgoing Money Transfer

496 Money Transfer Adjustment – Debit [1]

506 Book Transfer Debit

508 Individual International Money Transfer Debits

516 Foreign Transfer Debit

[1] Returned wires that are properly identified will be reported using codes ‘196’ and ‘496.’ Wires received without the proper designation may be reported as ‘195’ or ‘495.’

95

Data elements for inbound and outbound BAI2 files.

Inbound Wire Record Data (195, 196, 206, 208, 216 Record Types)

Outbound Wire Record Data (495, 496, 506, 508, 516 Record Types)

Credit Company Name Company Receiving Information

Credit Account Number Debit Account Number

Beneficiary Name Beneficiary Name

Dollar Amount Dollar Amount

Sender Name Sender Reference

ABA Number Receiver ABA Number

FED Reference Number Receiver Name

Date FED Reference Number

Time Date

Originating Bank Name Time

Originator Name Originating Bank Name

Reference Information for Beneficiary Originator Name

Reference Information for Beneficiary

Record Code Details

File Header Record (01)The fields within the file header record include the receiving and originating information, plus the file properties. The below table highlights the data elements which are part of the file header.

BAI2 Standard Field Field Description Field Format

Record Code 01

Sender Identification Transmitter of fileThe ABA of the sending institution

Alphanumeric

Receiver Identification Next recipient of the fileThe ABA of the next receiving institution

Alphanumeric

File Creation Date Date the sender created the file YYMMDD

File Creation Time Time the sender created the file Military format

File Identification Number Bank generated

Number will be incremented by one for each file at

the start of the day

Uniquely identify each file generated throughout

the day

Number

Defined by the sender

Physical Record Length Number of characters in a physical record Optional

Block Size Number of physical records in a block Optional

Version Number File version 2

Group Header (02)The group header identifies a group of accounts stemming from the same originator bank and same as-of-date.


Record Code 02

Ultimate Receiver Identification Final receiver of this group of data Optional

Alphanumeric

Originator Identification Originator of the group of data Alphanumeric

96

Group Status Update – Updates all status, summary and detail data

Deletion – Removes all previous data for the account

group indicated on the as-of-date field

Correction – Transmitted data can be deleted and

replaced with corrected data

Test Only – File to used for testing purposes; will not

impact production files

Numeric

One digit

As-of-Date Originator date YYMMDD

As-of-Time Reference only Optional

Military format

Currency Code Default is “USD” Optional

As-of-Date Modifier Interim previous-day data

Final previous-day data

Interim same-day data

Final same-day data

Optional

Account Identifier (03)This record will include the account information such as the account number, summaries and balances. The “03” record identifies each account within the BAI2 file.


Record Code 03

Customer Account Number Customer account number at originator

financial institution

Alphanumeric

Significant leading zeroes

No commas “,” or slash “/”

Currency Code Default is group currency code Optional

Transaction Detail Record (16)The transaction detail record will hold the transactional details reported by only one Type 16 record. The transactional details will be for those accounts identified within the 03 record.


Record Code 16

Type Code Identifies the type of detail data Required

Amount Defined by Currency Code in a group header record or

in an account identifier

Default is no amount being reported

Optional

Always positive

Expressed without a decimal

97


Funds Type Types are:

(0) immediate availability

(1) one-day availability

(2) Two-or-more-day availability

(S) Distributed availability

(V) Value dated

(D) Distributed availability

(Z) Unknown (default)

If “S”, the next three fields are immediate

availability amount, one-day availability amount, and

more than one-day availability amount.

If “V”, the next two fields are value date

(YYMMDD) and time (2400)

Optional

Bank Reference Number Defined by the originator Optional

Alphanumeric field

Must not contain a comma “,” or

a slash “/”

Customer Reference Number Defined by the originator

Bank defined

Alphanumeric field

Must not contain a comma “,” or

a slash “/”

Text Defined by the originator

Identifies transaction type

Optional alphanumeric

Must not begin with a slash “/”

May contain a comma “,” or a

slash “/” after first character

Continuation Record (88)The continuation record indicates a record has exceeded the standard physical size. The 88 record allows the record data from the previous record to continue in the same format. The 88 record can be preceded by another continuation 88 record, or any other type of record.


Record Code 88

Next Field Continuation of the preceding record data Same formatting as preceding record

If the preceding physical record does

not end with a text field, that record

should end with a delimiter slash “/”

98

Account Trailer Record (49)The account trailer summarizes totals at the account level. The 49 record provides the account control totals for the previous 03 record.


Record Code 49

Account Control Total Sum of all the “Amount” fields from the preceding

type 03 record and associated type 16 and 88

records.

Default value is positive

Includes the sign “+” and “-“ for the

total

Number of Records The total number of records as part of the 03

account.

Total includes the 03,16, 88 and 49 records

Integer

Group Trailer (98)The group trailer summarizes totals at the group level. All fields are required as part of the 98 record.


Record Code 98

Group Control Total Sum of all the “Amount” fields in this group Default value is positive


total

Number of Accounts The total number of 03 records in the group Integer

Number of Records The total number of records in this group

Total includes the 02, 03, 16, 88, 49 and 98 records

Integer

File Trailer (99)The file trailer record provides totals for the file. All fields within the file trailer are required.


Record Code 99

File Control Total Sum of all group totals in this file Default value is positive


total

Number of Groups The total number of 02 records in the file Integer

Number of Records The total number of records in the file

Total includes the 01, 02, 03, 16, 88, 49, 98, and 99

records

Integer

99

BA12 File Mapping Template

The following table illustrates BAI2 file mappings for the BAI2 wire file to be used to map to your system’s banking fields.

Inbound (195)/Outbound (495) Record Code Standard BA12 Field

195, 196, 206, 208, 216, 495, 496, 506, 508, 516 01 Sender Identification

195, 196, 206, 208, 216, 495, 496, 506, 508, 516 01 Receiver Identification

195, 196, 206, 208, 216, 495, 496, 506, 508, 516 01 File Creation Date

195, 196, 206, 208, 216, 495, 496, 506, 508, 516 01 File Creation Time

195, 196, 206, 208, 216, 495, 496, 506, 508, 516 02 Ultimate Receiver Identification

195, 196, 206, 208, 216, 495, 496, 506, 508, 516 02 Originator Identification

195, 196, 206, 208, 216, 495, 496, 506, 508, 516 02 File Creation Date

195, 196, 206, 208, 216, 495, 496, 506, 508, 516 02 File Creation Time

195, 196, 206, 208, 216 03 Customer Account Number (Beneficiary Name - BNF)

495, 496, 506, 508, 516 03 Customer Account Number (Originating Bank Info - OBI)

195, 196, 206, 208, 216, 495, 496, 506, 508, 516 16 Amount

195, 196, 206, 208, 216 16 Bank Reference Number

495, 496, 506, 508, 516 16 Bank Reference Number

195, 196, 206, 208, 216 16 Customer Reference Number (Bank Defined)

495, 496, 506, 508, 516 16 Customer Reference Number (Bank Defined)

195, 196, 206, 208, 216 88 FROM:

195, 196, 206, 208, 216 88 BY ORDER OF:

195, 196, 206, 208, 216, 495, 496, 506, 508, 516 88 VIA:

195, 196, 206, 208, 216, 495, 496, 506, 508, 516 88 SENDERS REF#:

195, 196, 206, 208, 216, 495, 496, 506, 508, 516 OUR REF#: (Bank Defined)

195, 196, 206, 208, 216, 495, 496, 506, 508, 516 88 TIME:

195, 196, 206, 208, 216 88 FOR PMT TO:

495, 496, 506, 508, 516 88 FOR PMT TO:

195, 196, 206, 208, 216 88 BNF:

495, 496, 506, 508, 516 88 BNF:

195, 196, 206, 208, 216 88 OBI:

495, 496, 506, 508, 516 88 OBI:

195, 196, 206, 208, 216, 495, 496, 506, 508, 516 88 RFB:

195, 196, 206, 208, 216, 495, 496, 506, 508, 516 88 BBK:

195, 196, 206, 208, 216, 495, 496, 506, 508, 516 88 BBI:

195, 196, 206, 208, 216 88 FED REF#:

100

GlossaryWe defined some of the commonly used terms and acronyms in this user guide. Whenever possible, we used the standard definition from the Association of Financial Professionals (AFP) or NACHA (National Automated Clearing House Association).

ABA Number

See Routing/transit number.

Account Analysis Statement

A paper or electronic report that a bank provides to commercial customers specifying services provided, balances maintained, volumes processed, and charges assessed. It is essentially an invoice for services provided, along with detailed information on balances and credit earned for those balances. When the report is provided electronically, it is often referred to as an “822”, which stands for the format used to send account analysis statements electronically.

Account Reconciliation

Banks provide account reconciliation services to meet companies’ information and control requirements. Partial or full reconciliation services are available and the information is transmitted to the company on paper report and/or on an output file using a direct transmission or through a website.

Automated Clearing House (ACH)

The ACH system was developed by the financial industry in the early 1970s as an electronic alternative to checks. The ACH system is a batch processing system traditionally designed for high volume, low value transactions. In an ACH transaction, payment information is processed and settled electronically, thereby increasing reliability, efficiency, and cost-effectiveness.

ACH Batch Files

A batch is a group of records considered a single unit for the purpose of data processing. An ACH batch file refers to a group of ACH batches initiated into the ACH network A file may contain one or more batches of entries. The ACH network is a batch processing, store-and-forward system. Transactions received by financial institutions during the day are stored and processed later in batch mode.

ACH Debit Block

An ACH debit block rejects all ACH debit presentments and is an electronic payment authorization service that protects account holders against fraudulent ACH debits.

ACH Debit Filter

An ACH debit filter is an electronic payment authorization service that forwards to the issuing company any transactions not authorized under specific, pre-established screen criteria for review. Such debits may be rejected depending upon the guidelines established between the company and the financial institution.

ACH Exposure Limit

The total dollar amount of an ACH file that has been approved by BBVA. The exposure limit is determined during the ACH credit approval process.

ACH Operators

ACH operators, also called processors, act as intermediaries between financial institutions by receiving, sorting and distributing ACH transaction files. For many financial institutions, including BBVA, the Federal Reserve Bank functions as the ACH operator for processing files, and they process the bulk of ACH transactions, with the remainder being processed by a private operator, the Electronic Payments Network (EPN).

101

ACH Participants

No matter which type of ACH transaction you choose to originate, the basic process is the same. Typically, there are five parties involved in an ACH transaction:

• The originating company

• The Originating Depository Financial Institution (ODFI)

• The ACH operator

• The Receiving Depository Financial Institution (RDFI)

• The receiving company, employee, or customer

ACH OperatorThe ACH operator is the central clearing facility operated by a private organization, or a Federal Reserve Bank. ACH entries are transmitted to and from participating depository financial institutions through the ACH operator.

ACH Transaction Flow

The transaction flow for both ACH debits and credits is the same. The difference is what happens to your company’s bank account. If you are originating ACH credits, then your bank account will be debited. If you are originating ACH debits, then your bank account will be credited. An easy way to keep track of this is to look at the impact on the receiver. If you debit that entity, you increase your cash account. If you credit that entity, you decrease your cash account.

All ACH entries follow the same basic transaction flow.

Step One: The receiver authorizes the originator to initiate electronic entries to and/or from their account.

Step Two: The originator creates and sends the ACH entries to their ODFI for processing.

Step Three: The ODFI verifies the format of the file and processes any transactions that are to be posted to the accounts of its own customer base. These entries are referred to as “on us” items.

Step Four: The ODFI passes the “foreign” transactions to the ACH operator.

Step Five: The ACH operator validates, balances, and prepares the ACH entries for each RDFI.

Step Six: The ACH operator transmits the appropriate entries to each RDFI.

Step Seven: The RDFI receives the entries and validates them. The entries are then posted (debited or credited)to the individual account on the settlement date, (e.g. the day you want the individual debited/credited).

Step Eight: On the settlement date, the ODFI credits/debits the originator’s bank account, as appropriate.

ACH Payment FormatsAll ACH payment formats move funds in essentially the same manner. The most appropriate format for a particular payment is determined by the relationship between the parties, the information exchanged and the types of ACH payment services offered by the participating banks. The basic ACH formats are as follows:

Pre-arranged Payment or Deposit (PPD): The PPD format is the payment application in which consumers authorize a company or financial institution to credit or debit an account for normally recurring payments in fixed amounts. Examples of consumer PPD credits are payroll, expense reimbursement, dividends, Social Security, retirement benefits, and tax refunds. Examples of consumer PPD debits are rent and mortgage payments, subscriptions, dues and memberships, insurance premiums, installment debt payments, and utility payments. This is sometimes referred to as Direct Deposit of Payroll.

Corporate Credit or Debit (CCD): CCD is a NACHA Standard Entry Class (SEC) Code (also called Cash Concentration or Disbursement), which can be either a credit or debit application where funds are either distributed or consolidated between corporate entities. Cash Concentration can either be a debit or a credit whereby funds are either distributed or consolidated between your various entities. Cash Disbursement can be used to settle trade payables or receivables. This application can serve as a standalone funds transfer, or it can support a limited amount of payment related data with the funds transfer. Note: Anytime you debit/credit a business bank account a signed authorization must be obtained, either on a separate document or as part of your contractual agreement with the business customer, before the transaction occurs.

102

Corporate Credit or Debit Plus Addendum (CCD+): Similar to CCD, except that the payment related information is included in the addenda record.

Corporate Trade Exchange (CTX): The Corporate Trade Exchange application supports the transfer of funds (debit or credit) in which a full ANSI ASC X12 message or payment related UN/EDIFACT information is included with the transfer. This information is placed in multiple addenda records.

Re-Presented Check Entries (RCK): Re-presented Check Entry is an ACH application used by companies to collect payment after a check has been processed through the check collection system, then returned because of insufficient or uncollected funds.

Accounts Receivable Conversion/Truncation (ARC): An ACH debit of a check received in the U.S. Mail and converted to an electronic item. The definition of U.S. Mail includes mail delivered by the United States Postal Service, as well as mail delivered by courier service, including but limited to: Federal Express, United Parcel Service, or other local courier services. This does not include items personally delivered or deposited in a merchants night drop; these checks are not considered to have been delivered by U.S. Mail and are not eligible for truncation. Corporate checks are also not eligible for truncation.

Point-of-Purchase (POP): This ACH debit application is used by originators as a method of payment for the in-person purchase of goods or services by consumers. These single entry debit entries are initiated by the originator based on a written authorization and account information drawn from the source document (a check) obtained from the consumer at the point-of-purchase. The source document, which is voided by the merchant and returned to the consumer at the point-of-purchase, is used to collect the consumer’s routing number, account number, and check serial number that will be used to generate the debit entry to the consumer’s account.

Telephone Initiated Entry (TEL): This standard entry class code is used for the origination of a single entry debit transaction to a consumer’s account, pursuant to an oral authorization obtained from the consumer using the telephone. This type of transaction may only be originated when there is either (1) an existing relationship between the originator and the receiver, or (2) no existing relationship between the originator and the receiver, but the receiver has initiated the telephone call. This SEC code facilitates access to the ACH network by providing an alternative authorization method, oral authorization using the telephone, for certain types of consumer debit entries. Note: All TEL transactions must be recorded and the recordings must be kept on file for at least 2 years after the transaction date.

internet Initiated Entry (WEB): A debit entry to a consumer account initiated by an originator pursuant to an authorization that is obtained from the receiver through the internet. There are two components of the definition that are important to address:

• The WEB SEC code is only appropriate to use when initiating debit entries that have been authorized by the receiver through the internet. An authorization that was obtained from the receiver in person, through the mail, or over the telephone in order to effectuate an internet payment is not to be initiated as a WEB transaction.

• Credit entries cannot be initiated except for reversals of WEB debit entries.

Back Office Conversion (BOC): The Back Office Conversion (BOC) application will allow retailers and billers to accept checks at the point of purchase or at manned bill payment locations and convert the checks to ACH debits during back office processing. The authorization to convert the check is obtained through receipt of the customer’s (receiver’s) check (source document) plus notice displayed at the point of sale or manned bill payment location where the check is presented. Businesses that will be converting checks using BOC must post a notice in a prominent and conspicuous location, and must provide a copy to the customer on the receipt or another takeaway at the time of the transaction. Customers authorize conversion of their checks by signing the checks after they have been provided with notification. The business is required to provide customers with an opt-out option. The originator must have procedures to identify ineligible items and process those items as presented.

ACH Transactions (ODFI & RDFI)ACH transactions may be credits or debits. Consequently, the terms “payor” and “payee” are not used to identify the parties to an ACH transaction. Instead, the terms “originator” and “receiver” are used. Financial institutions that act as intermediaries between the originator and the receiver are referred to as the Originating Depository Financial Institution (ODFI) and the Receiving Depository Financial Institution (RDFI) respectively. ACH transactions are value dated, that is, the payment instructions include the settlement dates, which generally one or two business days after the file is sent to the ODFI. For more information see “Same Day ACH Origination” on page 39.

103

Addenda RecordAn ACH record type that carries supplemental data needed to completely identify an account holder, or to provide information concerning a payment to the receiver.

Authorization (specific to ACH)A written agreement with the originating company signed or similarly authenticated by an employee or customer to allow payments processed through the ACH network to be deposited or withdrawn from their account at a financial institution.

Auxiliary-on-us (Aux-on-us) FieldThe auxiliary-on-us field is a part of a deposit ticket’s magnetic ink character recognition (MICR) line and carries a unique identifier for each company location, thereby enabling the bank to produce deposit reports on a daily, weekly or monthly basis. It is also called the serial (check) number on a business check. See MICR line definition for more details.

Average Collected BalanceThe sum of the daily ending collected balances (both positive and negative) divided by the number of days in the analysis period.

Balanced FileA balanced file contains an offsetting entry to your BBVA account. For example, in a direct deposit of payroll file you may have five entries for five employees, for a total payroll file of $10,000. Contained with in that file would be an offsetting debit to your BBVA account in the amount of $10,000. BBVA accepts unbalanced files only.

Batch Header RecordA record within a file that identifies a unique batch. Also known as the “5 Record.”

Batch Posting & ProcessingBatch processing refers to a group of checks, drafts, or items handled as a unit to be processed in a single program run. Batch posting refers to an item that is handled during batch processing. In almost all cases, batch processing is scheduled to run after branch banking hours and when online customer activity is at a minimum, usually between 10:00 p.m and 6:00 a.m. For more information see “Same Day ACH Origination” on page 39.

Cash ConcentrationThe consolidation of funds from many financial institutions into one central account.

Check ConversionTransforming a payment initiated by paper check that has not been negotiated to an electronic payment.

Check TruncationCheck truncation converts the information on a business or consumer check into an electronic form or image that is transmitted electronically, thereby avoiding the need for physical presentment of the item.

Controlled DisbursementService wherein the company is notified early in the day of the dollar amount of items waiting to clear the account later that day; the company funds the account with the exact amount to clear the items.

104

Data ExchangeYou can establish a consolidated cash position for all your locations nationwide or globally — even if you have multiple accounts with different financial institutions. With multi-bank information reporting, you eliminate the need for multiple bank transmissions, software, or phone calls just to get account information. It also allows you to consolidate all your account activity into a single download.

Inbound Multi-Bank Information Reporting to receive other banks’ account information. With Inbound multi-bank information reporting, BBVA is the lead bank and receives a daily transmission from your various financial institutions. BBVA then combines this information with your BBVA account information and provides you with a consolidated report of your account balances through BBVA Net Cash. Or you may choose to receive your inbound data in a file transmission from BBVA.

Outbound Multi-Bank Information Reporting to send your BBVA account information to other financial institutions. With outbound multi-bank information reporting, we send a daily transmission of your BBVA account information to the bank of your choice. This bank, called the lead bank, combines this information with your other banks’ information to provide consolidated reporting of your company’s daily cash position.

Demand Deposit Account (DDA)An account from which a depositor may withdraw funds immediately without prior notice, commonly known as a checking account. Since funds may be withdrawn on demand in person or by presentation of a check, the account has many of the liquid characteristics of circulating currency.

Deposit Reconciliation ServiceIdentifying, crediting, and reporting deposits from multiple locations into a single corporate account. The deposits are reconciled through a process of adjusting an account balance reported by a bank to reflect transactions that have occurred since the reporting date.

Digital CertificatesAn electronic credential that establishes a party’s identity for the purpose of conducting electronic business or electronic transactions. It is a tamper-proof electronic file that is issued by a certification authority, and typically contains the owner’s name, public key, and related information. A certificate attests that the included public key and its corresponding private key belong to the owner of the certificate.

Digital certificates are required to send and receive files using secure file transfer protocol. You can use your own digital certificate, provided it conforms to one of the supported hashing algorithms, or you can have BBVA issue a digital certificate to you.

Digital SignatureAn electronic signature that can be used to authenticate the identity of the sender of a message or signer of a document. It can also be used to ensure that the original content of the message or document has not been altered since it was signed. Unlike the handwritten signature, the digital signature is unique to every document to which it is applied. It is widely regarded as the most secure and full-featured type of electronic signature. A digital signature makes use of the fact that it is possible to calculate a unique numeric value for any given document by using a hashing algorithm. This value (called a hash or digest) can be encrypted using the signer’s private key. The result is the digital signature. The digital signature can be “verified” by decrypting it with the signer’s public key.

Digitized SignatureAn electronic representation of an actual handwritten signature. The image of a handwritten signature may be created and saved using various methods, such as using a signature pad, scanning a wet signature or digital photography. Signature pads allow the user to sign onto a small pressure-sensitive tablet, or even onto a superimposed paper receipt. The most sophisticated signature pads capture the signature and bind it to the body of the document to prevent changes or tampering after signing. A digitized signature may contain data on the direction and speed of the pen/stylus, the shape of the letters, and other unique characteristics of the actual signing technique. Alternatively, the digitized signature may be comprised of the visible image only. The

105

signature may be “captured” in real time (at the time the user applies the signature), or a previously saved image may be applied.

Direct Debit or PaymentAn ACH method used to collect funds from customers for recurring payments.

Direct DepositAn ACH method used to disburse funds to employees for some type of compensation – usually payroll, expense reimbursement, dividends, etc.

Electronic CheckA payment that begins as a paper check is converted into, or truncated to, an ACH debit entry. The paper check is not processed.

Earnings Credit Rate (ECR)The rate used by banks to determine the allowable credit they will provide for the use of a customer’s balances on deposit with them.

Electronic Data Interchange (EDI)EDI is the computer-to-computer exchange of business data in standard formats. In EDI, information is organized according to a specified format set by both parties, allowing an automated computer transaction that requires no human intervention or rekeying on either end. The information contained in an EDI transaction set is, for the most part, the same as on a conventionally printed document. EDI standards in the US are set and published by the ASC X12 committee of ANSI. International EDI standards are known as EDIFACT standards.

EncryptionThe translation of data into a secret code. Encryption is the most effective way to achieve data security. Unencrypted data is called plain text; encrypted data is referred to as cipher text.

Forged CheckA check which was endorsed and cashed by a person other than the payee.

Hypertext Transfer Protocol Secured (HTTPS)HTTPS is the Hyper-Text Transfer Protocol with SSL encryption. It is the most popular network protocol for establishing secure connections for exchanging documents on the web. It is basically HTTP carried over a TCP socket, which has been secured using SSL.

Image Cash Letter (ICL)Banks have entered into agreements with each other to electronically present checks to the paying bank using ICLs. The ICL file format contains data and check images in a tagged image file format in lieu of a physical paper cash letter. A cash letter contains checks accompanied by a letter (e.g., cover sheet) that lists the amounts and instructions for the transmittal of the checks to another bank.

Image Replacement Document (IRD)As a result of the Check Clearing for the 21st Century Act (Check 21), check truncation converts the information on a business or consumer check into an electronic form or image that is transmitted electronically, thereby avoiding the need for the physical presentment of the item. If the drawee bank’s customer wants the check returned in a statement, Check 21 allows the drawee bank to create a substitute check that is sometimes referred to as an IRD.

106

LockboxFinancial institution or third party processor service that facilitates rapid collection and posting of corporate receivables. Typically, customer payments are mailed to a lockbox or mailbox for collection, sorting, totaling, and recording by the bank or provider rather than by the billing organization.

Magnetic Ink Character Recognition (MICR) LineMICR line refers to the characters on the bottom line on the face of a paper check that contains the routing/transit number of the financial institution the check is drawn on, the account number of the drawee (receiver), and the check number, all printed in machine readable magnetic ink in a font devised for check reading.

The MICR line has an established format that can cause rejects if the format conventions are not followed. The fields are, from right to left:

Amount field, positions 1-12

On-Us field, positions 14-31

Transit field, positions 33-43

Auxiliary On-Us field, positions 45-65

The picture shown below explains the various positions of the MICR line on a business check.

The amount field is kept blank and is filled-in by the bank of first deposit when the check is presented for payment.

The arrangement of characters and symbols in the on-us field is determined by BBVA. These characters must be reproduced exactly as specified.

The transit field identifies the institution upon which the check is drawn. BBVA has different transit and routing numbers for each state where accounts are opened. Be sure to refer to the MICR specifications document you were provided by the BBVA implementation coordinator to ensure you have the correct transit and routing numbers for the account.

The AUX on-us field contains the check serial number bracketed by on-us symbols.

MICR Specification DocumentThe MICR specification document is provided during account opening and it is available upon request from BBVA implementation coordinators. It contains the characters and numbers that must be used in the transit and on-us fields for the checks to be correctly processed by banks.

Multi-Bank ReportingSee Data Exchange.

107

Multi-Factor AuthenticationMultifactor authentication (MFA) is a security system in which more than one form of authentication is implemented to verify the legitimacy of a transaction. In contrast, single factor authentication (SFA) involves only a user ID and password. In two-factor authentication, the user provides dual means of identification, one of which is typically a physical token, such as a card, and the other of which is typically something memorized, such as a security code. Additional authentication methods that can be used in MFA include biometric verification such as fingerscanning, iris recognition, facial recognition, and voice ID. In addition to these methods, smart cards and other electronic devices can be used along with the traditional user ID and password.

National Automated Clearing House Association (NACHA)The national trade association for electronic payment associations, which establishes the rules, industry standards and procedures governing the exchange of commercial ACH payments by depository financial institutions.

Network A system of channels and interconnections such as among financial institutions, processors, and merchants.

Notification of Change (NOC)Information sent by a Receiving Depository Financial Institution (RDFI) to the Originating Depository Financial Institution (ODFI) to notify them that previously valid information for a receiver has become outdated, or that the information contains an error. This information is then passed to the originator so that their records can be updated. The standard entry class code is COR.

Offsetting EntryAn entry in an ACH file used to credit or debit the originator’s bank account for the total amount of the batch or file.

On-Us EntriesEntries within an ACH file that are to be debited or credited to accounts held by the ODFI.

Originating Depository Financial Institution (ODFI)

The ODFI is the financial institution that receives payment instructions from originators and forwards those entries to the ACH operator.

Originator

The originator is the entity that agrees to initiate ACH transactions into the ACH system according to an arrangement with the receiver.

Personal Identification Number (PIN)This is a security procedure used to identify authorized users.

Point-of-Sale (POS)Capturing data at the time and place of sale. Point-of-sale systems use personal computers or specialized terminals that are combined with cash registers, optical scanners for reading product tags, and/or magnetic stripe readers for reading credit cards.

Positive PayThis service matches check serial numbers and dollar amounts against a company’s issue file, thereby enabling a bank to determine which checks can be paid and which should be returned. Items that do not match the issue file are reported as exceptions.

108

Pre-Authorized DebitsThe payee has written authorization to debit the payor’s account for a specific amount at specific intervals. Used primarily for mortgage or loan payments, insurance premiums, monthly dues, leases, tuition or charitable contributions.

Pre-notifications (Prenotes)A non-dollar (zero dollar) entry that may be sent though the ACH Network to, (a) notify the RDFI that live dollar entry is forthcoming, or (b) request the RDFI verify the receiver’s account number.

Public & Private Encryption KeysA pair of mathematically related encryption keys. Knowledge or possession of one key of the pair does not allow calculation of the other key. Data encrypted using one key can only be decrypted using the other key of the pair. The private key must be securely held by the owner, while the public key may be freely distributed, often within a digital certificate.

Receiver

A receiver is an individual or organization that has authorized the originator to initiate an ACH entry to the receiver’s account with the RDFI.

Receiving Depository Financial Institution (RDFI)

The RDFI is the financial institution that receives ACH entries from the ACH operator and posts those entries to the accounts of its receivers.

Remote DepositProcess by which a company scans and images checks and transmits them to the bank instead of physically depositing the checks at a bank branch or cash vault.

Return ItemCheck that was returned without payment.

Reverse Positive PayWe provide a list of checks presented for payment to the company on a daily basis. The company matches this to a list of checks issued and notifies BBVA of any checks to be returned.

ReversalsAny ACH entries or files sent within required deadlines to correct or reverse originated entries or files.

Routing/Transit NumberAlso known as routing number, transit/routing number, and ABA number. A nine digit number (eight digits plus a check digit) which identifies a specific financial institution. Routing numbers are administered by the Routing Number Administrative Board under the sponsorship of the American Bankers Association and officially maintained and published by Thomson Financial Publishing.

Same Day CreditBank credit provided for transactions the same business day.

Sarbanes-Oxley (SOX)The Sarbanes Oxley Act is a set of rules put together by the U.S. government in an effort to improve a

109

company’s audit. All companies (both foreign and domestic) that have registered equity or debt securities under the Securities Exchange Act of 1934 are subject to the SOX Act. Foreign public accounting firms must also comply with the Act if they perform work for companies subject to the Act. One of the most important goals of the SOX Act is to ensure that company directors and officers are aware of and accountable for the financial condition of the companies they manage. SOX directs the SEC to subject securities analysts to stricter rules regarding conflicts of interest. SOX prevents auditors from providing bookkeeping services, financial information systems design, appraisals, valuations, fairness opinions, actuarial services, management functions, human resources, broker/dealer, investment banking, investment advisory, legal, or other services to clients.

Settlement DateThe date on which the exchange of funds takes place. For more information see “Same Day ACH Origination” on page 39.

Standard Entry Class (SEC) CodeNACHA requires that when a transaction is submitted to the Federal Reserve for processing, the transaction must include something called a Standard Entry Class (SEC) code to communicate exactly how the customer gave you authorization to debit/credit their bank account. There are only a few authorization methods allowed by NACHA, so the list of SEC codes is very short.

The following table shows the proper SEC codes to use depending on how you obtained the authorization to debit/credit an individual or company’s bank account

Standard Entry Class (SEC) Code

ARC BOC CCD POP

SEC Description Accounts Receivables Back Office Conversion Cash Concentration and

Disbursement

Point of Purchase

Type of Application Convert checks received

by mail or drop box

without an auxillary

on-us field

Convert checks received

in person without an

auxillary on-us field in

back office

Cash concentration;

child support, corporate

and, tax payments

Convert checks received

in person without and

auxillary on-us field at

point of purchase

Debits or Credits Debits only Debits only Debits or credits Debits only

Single or

Recurring Entries

Single Single Single or

Recurring entries

Single

Type of Authorization Notice, usually on each

bill or a sign posted at

each drop box location

Notice at point of

purchase and takeaway

notice

By agreement between

the originator and

receiver

In writing and signed;

consumer signs receipt

at point of purchase

Who Retains Check Originator Originator N/A Consumer

Check Retention Period Check or copy must be

retained for 2 years

Check or copy must be


N/A N/A - Check returned at

point of purchase

Number of ACH

Presentments

Allowed

3 3 3 3

Dollar Limit $25,000 $25,000 None $25,000

Dispute Timeframe Up to 60 days after

settlement

Up to 60 days after

settlement

24 hours Up to 60 days after

settlement

110

Standard Entry Class (SEC) Code

PPD RCK TEL WEB

SEC Description Prearranged payment or

deposit

Returned check Telephone initiated internet initiated

Type of Application Direct deposit of payroll,

consumer debits

Consumer checks

returned for insufficient

or uncollected funds

Consumer payment

authorized on telephone

Consumer payment

authorized on the

internet

Debits or Credits Debits or credits Debits only Debits only Debits only

Single or

Recurring Entries

Single or

recurring entries

Single Single or

Recurring entries*

Single or

recurring entries

Type of Authorization In writing and signed,

debits only

Notice prior to receiving

the check

Verbal, must be recorded

or confirmed in writing

Signed or “similarly

authenticated” online

Who Retains Check N/A Originator or CPS N/A N/A

Check Retention Period N/A Check or copy must be


N/A N/A

Number of ACH

Presentments

Allowed

3 2 3 3

Dollar Limit None $2,500 None None

Dispute Timeframe Up to 60 days after

settlement

Up to 60 days after

settlement

Up to 60 days after

settlement

Up to 60 days after

settlement

*If it is recurring it is necessary to send the customer a copy of the authorization. This is for either an existing customer(done business with

your company within the last two years) or customer initiated the call. See current year NACHA Operating Rules and Guidelines for more

details.

If NACHA decides to audit a merchant or processor, as part of the audit process they may require proof of the authorization method (SEC code) specified for any given transaction. Failure to properly comply and provide proof of the authorization can result in fines up to $10,000 for each transaction in violation, so it is important that you correctly indicate the SEC code and maintain good records of your authorizations.

Substitute Check

See Image Replacement Document (IRD).

Token

A small, portable hardware device that can securely store a cryptographic (private) key used to authenticate the claimant’s identity.

Transit Routing Number (TRN)

Also known as routing number, transit/routing number, and ABA number. A nine digit number (eight digits plus a check digit) which identifies a specific financial institution. Routing numbers are administered by the Routing Number Administrative Board under the sponsorship of the American Bankers Association and officially maintained and published by Thomson Financial Publishing.

111

Unbalanced File

An ACH file that does not contain an offsetting entry to debit or credit the originator’s account. BBVA accepts ACH files in an unbalanced format.

Uniform Commercial Code (UCC)

The UCC is a uniform set of laws governing commercial transactions. The UCC defines the rights and duties of the parties in a commercial transaction and provides a statutory definition of commonly accepted business practices.

Zero Balance Account (ZBA)

A ZBA is a disbursement account on which a company issues checks, initiates ACH debits, or initiates wire transfers. The balance in the account is maintained at zero. A transfer of funds from a master account located in the same bank covers all debits against a ZBA. Some ZBAs are used for both collections and disbursements. Credits and debits that post to the ZBA are netted at the close of each business day.

TM-01-4003B rev. 06/19

BBVA and BBVA Compass are trade names of BBVA USA, a member of the BBVA Group. BBVA USA, Member FDIC. All accounts and credit are subject to approval, including credit approval.

Documents

User Guide Data Transmissions - BBVA USA...Ongoing Support Once you have established the connectivity and transmission set up, ongoing product support should be directed to your local