user guide data transmissions...4 direct channels file or report file transfer services bbva...
TRANSCRIPT
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
Electronic Report Delivery (ERD) 18
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
Electronic Report Delivery (ERD) 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
Standard BBVA ARP Output File Format Layout
Position Field Name Field Length
Field Type Format Comments
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
Standard BBVA ARP Output File Format Layout
Position Field Name Field Length
Field Type Format Comments
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
35 Alphanumeric Text with
commas
removed
Name of the wire recipient (payee), as listed on the
transaction.
20 Wire Originating
Party
35 Alphanumeric Text with
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
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘5’ Record Type Code
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
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.
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
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘5’ Record Type Code
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) 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
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.
9 51 -53 3 X(3) ‘IAT’ Standard Entry Class
Code
10 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.
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.
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘6’ Record Type Code
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.
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘6’ Record Type Code
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 credit
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
or vendor banks. Beware of numbers that
do not begin with a 0, 1 or 2. Those are NOT
routing numbers.
4 12 1 9 Check Digit This is the last digit of the routing number.
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
or debiting the receiver. The decimal point is
implied, not hard coded.
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
digits must be incremented by 1 for each
entry detail record.
24
Entry Detail Record - The Six RecordFormat: IAT
Each record contains information about the receiver.
PPD/CCD Addenda Record Format
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘6’ Record Type Code
2 02-03 2 9(2) Transaction Code Choose the appropriate Transaction Code
from the 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 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.
Enter ‘06200118’ for PaySource Card entries.
4 12 1 9 Check Digit This is the last digit of the routing number.
Enter ‘6’ for PaySource Card entries.
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
implied, not hard coded.
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.
9 75-76 2 Blank Reserved
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
digits must be incremented by 1 for each
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
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘7’ Record Type Code
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
entry detail record.
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
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘7’ Record Type Code
2 02-03 2 9(2) ‘10’ Addenda Type Code
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
Field Position Size Picture Contents Data Name Comments
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
or debiting the receiver. The decimal point is
implied, not hard coded.
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.
7 82-87 6 Blank Reserved
8 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
entry detail record.
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
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘7’ Record Type Code
2 02-03 2 9(2) ‘11’ Addenda Type Code
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.
5 74-87 14 Blank Reserved
6 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
entry detail record.
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
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘7’ Record Type Code
2 02-03 2 9(2) ‘12’ Addenda Type Code
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.
5 74-87 14 Blank Reserved
6 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
entry detail record.
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
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘7’ Record Type Code
2 02-03 2 9(2) ‘13’ Addenda Type Code
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
Field Position Size Picture Contents Data Name Comments
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’.
7 78-87 10 Blank Reserved
8 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
entry detail record.
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
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘7’ Record Type Code
2 02-03 2 9(2) ‘14’ Addenda Type Code
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.
Enter ‘062001186’ for PaySource Card entries.
6 75-77 3 X(3) ‘US’ Receiving DFI Branch
Country Code
7 78-87 10 Blank Reserved
8 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
entry detail record.
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
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘7’ Record Type Code
2 02-03 2 9(2) ‘15’ Addenda Type Code
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
6 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
entry detail record.
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
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘7’ Record Type Code
2 02-03 2 9(2) ‘16’ Addenda Type Code
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.
5 74-87 14 Blank Reserved
6 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
entry detail record.
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
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘7’ Record Type Code
2 02-03 2 9(2) ‘17’ 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.
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.
4 84-87 4 9(4) Addenda Sequence
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’.
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
entry detail record.
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
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘7’ Record Type Code
2 02-03 2 9(2) ‘18’ Addenda Type Code
31
IAT Addenda Record for Foreign Correspondent Bank Information Format
Field Position Size Picture Contents Data Name Comments
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.
7 78-83 6 Blank Reserved
8 84-87 4 9(4) Addenda Sequence
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’.
9 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
entry detail record.
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
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘8’ Record Type Code
2 02-04 3 9(3) Service Class Code Select one of the following codes depending
on the type of ACH entries you 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.
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
Field Position Size Picture Contents Data Name Comments
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.
Your treasury management officer or
implementation coordinator will provide
this information to you. It is usually one digit
followed by your company’s TIN. This must
match the batch header record.
8 55-79 25 X(25) Blank Reserved
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
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘9’ Record Type Code
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.
7 44-55 12 9(10)V99 Total Credit Entry
Dollar Amount in File
This is the total dollar amount of all credit
entries in the file.
8 56-94 39 X(39) Blank Reserved
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)
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 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 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)
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘5’ Record Type Code
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
BBVA has established for your company.
Your treasury management officer and
implementation coordinator will provide
this information to you. It is usually one digit
followed by your company’s TIN.
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
7 54-63 10 X(10) Company Entry
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)
Field Position Size Picture Contents Data Name Comments
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.
36 Savings account automated return or NOC for original transaction codes 37, 38, or 39.
Entry Detail Record - The Six RecordFormat: CCD for both Returns and Notifications of Change
File Header Record Format - (TAPE-HEAD-BODY)
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘6’ Record Type Code
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
File Header Record Format - (TAPE-HEAD-BODY)
Field Position Size Picture Contents Data Name Comments
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.
31 Savings account automated return or NOC for original transaction codes 32, 33, or 34.
36 Savings account automated return or NOC for original transaction codes 37, 38, or 39.
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)
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘7’ Record Type Code
2 02-03 2 9(2) ‘99’ Addenda Type Code
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)
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘7’ Record Type Code
2 02-03 2 9(2) ‘98’ Addenda Type Code
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)
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘7’ Record Type Code
2 02-04 3 9(3) Service Class Code
SERV-CODE-GF
Select one of the following codes depending
on the type of ACH entries you 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.
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)
Field Position Size Picture Contents Data Name Comments
6 33-44 12 9(10)V99 Total Credit Entry
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)
Field Position Size Picture Contents Data Name Comments
1 01 1 9 ‘9’ Record Type Code
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
Filler 31 520 A Spaces
Payment Detail Record Layout
Field Name Position Length Type Data Name
Record Code 1 1 A ‘6’
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
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
46
Field Name Position Length Type Data Name
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
Field Name Position Length Type Data Name
CC MID 465 32 A Credit Card Payment MID (Only on CC transactions)
Principal Payment or Fee Payment MID (Only on CC
transactions)
Filler 497 54 A Spaces
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.
Field Name Position Length Type Data Name
Record Code 1 1 A ‘7’
Transaction type 2 2 A Type of transaction. Allowed types are:
70 Supplemental Record
Filler 4 3 A Blank
Payment ID 7 19 A Confirmation number of payment
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
Biller Remittance Field 2 176 50 N Data passed by the Biller as Biller Remittance Field 2
Biller Remittance Field 3 226 50 N Data passed by the Biller as Biller Remittance Field 3
Biller Remittance Field 4 276 50 N Data passed by the Biller as Biller Remittance Field 4
Biller Remittance Field 5 326 50 N Data passed by the Biller as Biller Remittance Field 5
Filler 376 175 A Spaces
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.
Field Name Position Length Type Data Name
Record Code 1 1 A ‘7’
Transaction type 2 2 A Type of transaction. Allowed types are:
71 Supplemental Record
Filler 4 3 A Blank
Payment ID 7 19 A Confirmation number of payment
Account number 26 100 A Same as on the corresponding ‘6’ record this
“Supplemental Record” applies to.
Short Pay Reason 126 250 A Short Pay Detail Text for the payment, entered by the
consumer for that individual short pay.
Filler 376 175 A Spaces
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.
Field Name Position Length Type Data Name
Record Code 1 1 A ‘6’
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)
Payment ID 7 19 A Confirmation number of payment
Account number 26 100 A Biller account number
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 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
Field Name Position Length Type Data Name
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)
Filler 445 106 A Spaces
Credit Memo Addendum Record Layout
(Standard A/R) Data Types:
Numeric (N) Right justified, leading zeroes
Alpha Numeric (A) Left justified, padded with spaces
Field Name Position Length Type Data Name
Record Code 1 1 A ‘7’
Transaction type 2 2 A Type of transaction. Allowed types are:
70 Supplemental Record
Filler 4 3 A Blank
Payment ID 7 19 A Confirmation number of payment
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
Biller Remittance Field 2 176 50 N Data passed by the Biller as Biller Remittance Field 2
Biller Remittance Field 3 226 50 N Data passed by the Biller as Biller Remittance Field 3
Biller Remittance Field 4 276 50 N Data passed by the Biller as Biller Remittance Field 4
Biller Remittance Field 5 326 50 N Data passed by the Biller as Biller Remittance Field 5
Filler 376 175 A Spaces
Record Code 1 1 A ‘7’
Transaction type 2 2 A Transaction Types Allowed:
Supplemental Record
Filler 4 3 A Blank
Payment ID 7 19 A Confirmation number of payment
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.
Filler 376 175 A Spaces
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.
Field Name Position Length Type Data Name
Record Code 1 1 A ‘8’
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
Filler 43 508 A Spaces
File Trailer Record Layout
Increased block size in reference to Standard A/R File.
One record per file
Field Name Position Length Type Data Name
Record Code 1 1 A ‘9’
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:
TTTT Federal reserve prefix
AAAA ABA institution identifier
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
Shall be present, unless omitted under clearing
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
Shall be present only under clearing
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).
Field Field Name Usage Position Size Type
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
A code that identifies the type of record.
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
Collection Type Indicator
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.
Destination Routing Number
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
AAAA ABA institution identifier
C Check digit
ECE Institution Routing Number
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:
TTTT Federal Reserve prefix
AAAA ABA institution identifier
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’
MM ‘01’ through ‘12’
DD ‘01’ through ‘31’
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’
MM ‘01’ through ‘12’
DD ‘01’ through ‘31’
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
Shall be present, unless omitted under clearing
arrangements.
Position
Size
Type
45 - 52
8
AN Alphameric
Originator Contact Name
A contact at the institution that creates the cash letter. Usage Conditional
Shall be present, unless omitted under clearing
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
A field used at the discretion of users of the standard. Usage Conditional
Shall be present only under clearing
arrangements.
Position
Size
Type
78 - 79
2
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
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).
Field Field Name Usage Position Size Type
1
2
3
4
5
6
7
8
9
10
11
12
Record Type
Collection Type Indicator
Destination Routing Number
ECE Institution Routing Number
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
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
‘20’ Bundle header record
Collection Type Indicator
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).
Destination Routing Number
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
AAAA ABA institution identifier
C Check digit
ECE Institution Routing Number
A number that identifies the institution that creates the
bundle header record.
Usage
Position
Size
Type
Format
Mandatory
14 - 22
9
N Numeric
TTTTAAAAC, where:
TTTT Federal Reserve prefix
AAAA ABA institution identifier
C Check digit
64
Bundle Business Date
The year, month, and day that designates the business
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
YYYY ‘1993’ through ‘9999’
MM ‘01’ through ‘12’
DD ‘01’ through ‘31’
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
YYYY ‘1993’ through ‘9999’
MM ‘01’ through ‘12’
DD ‘01’ through ‘31’
Bundle ID
A number that identifies the bundle, assigned by the
institution that creates the bundle.
Usage Conditional
Shall be present, unless omitted under clearing
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
Shall be present, unless omitted under clearing
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
Shall be present if available, unless omitted under
clearing arrangements.
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:
TTTT Federal Reserve prefix
AAAA ABA institution identifier
C Check digit
User Field
A field used at the discretion of users of the standard. Usage Conditional
Shall be present only under clearing
arrangements.
Position
Size
Type
64 - 68
5
ANS Alphameric/special
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).
Field Field Name Usage Position Size Type
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
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
‘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
Shall be present if available, unless omitted under
clearing arrangements.
67
Position
Size
Type
Format
05 – 13
9
N Numeric
TTTTAAAAC, where:
TTTT Federal reserve prefix
AAAA ABA institution identifier
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
Shall be present if available, unless omitted under
clearing arrangements.
Position
Size
Type
Format
Defined Values
14 - 21
8
N Numeric
YYYYMMDD, where:
YYYY year
MM month
DD day
YYYY ‘1993’ through ‘9999’
MM ‘01’ through ‘12’
DD ‘01’ through ‘31’
Endorsing Bank Item Sequence Number
A number that identifies the item at the endorsing bank. Usage Conditional
Shall be present if available, unless omitted under
clearing arrangements.
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
Shall be present only under clearing
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
Shall be present only under clearing
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
Shall be present only under clearing
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
A field used at the discretion of users of the standard. Usage Conditional
Shall be present only under clearing
arrangements.
Position
Size
Type
41 – 55
15
ANS Alphameric/special
Reserved
A field reserved for future use by the Accredited
Standards Committee X9.
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.
Field Field Name Usage Position Size Type
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
Field Field Name Usage Position Size Type
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
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
‘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:
TTTT Federal reserve prefix
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
Defined Values YYYY ‘1993’ through ‘9999’
MM ‘01’ through ‘12’
DD ‘01’ through ‘31’
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
Shall be present only under clearing
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
Shall be present if field 10 in this image view detail
record has defined value of 1.
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
Shall be present if field 10 in this image view detail
record has defined value of 1.
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
Shall be present only under clearing
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
A field used at the discretion of users of the standard. Usage Conditional
Shall be present only under certain clearing
arrangements.
Position
Size
Type
58 - 65
8
ANS Alphameric/special
Reserved
A field reserved for future use by the Accredited
Standards Committee X9.
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.
Field Field Name Usage Position Size Type
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 h2
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
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
‘52’ Image view data record
ECE Institution Routing Number
A number that identifies the institution that creates the
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
Bundle Business Date
The year, month, and day that designates the business
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
Defined Values YYYY ‘1993’ through ‘9999’
MM ‘01’ through ‘12’
DD ‘01’ through ‘31’
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
Shall be present if available, unless omitted under
clearing arrangements.
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
Shall be present only under clearing arrangements
and when field 10 in the related Image view detail
record (type 50) has defined value of 1.
Position
Size
Type
37 - 52
16
ANS Alphameric/special
Security Authenticator Name
Unique designation of the entity that performs
authentication on received data.
Usage Conditional
Shall be present only under clearing arrangements
and when field 10 in the related image view detail
record (type 50) has defined value of 1.
Position
Size
Type
53 - 68
16
ANS Alphameric/special
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
Shall be present only under clearing arrangements
and when field 10 in the related image view detail
record (type 50) has defined value of 1.
Position
Size
Type
69 - 84
16
ANS Alphameric/special
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
Clipping Coordinate h1
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
Shall be present if clipping origin (field 9) in this
image view data record is non-zero.
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
Shall be present if clipping origin (field 9) in this
image view data record is non-zero.
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
Shall be present if clipping origin (field 9) in this
image view data record is non-zero.
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’
ANS Alphameric/special
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
Variable (see table)
‘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
Variable (see table)
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.
Field Field Name Usage Position Size Type
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
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
‘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
Shall be present only under clearing arrangements.
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
Shall be present only under clearing arrangements.
Position
Size
Type
31 - 35
5
N Numeric
User Field
A field used at the discretion of users of the standard. Usage Conditional
Shall be present only under clearing arrangements.
Position
Size
Type
36 - 55
20
ANS Alphameric/special
Reserved
A field reserved for future use by the Accredited
Standards Committee X9.
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.
Field Field Name Usage Position Size Type
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
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
‘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
Shall be present only under clearing
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
Shall be present, unless omitted under clearing
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
Shall be present only under clearing
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’
MM ‘01’ through ‘12’
DD ‘01’ through ‘31’
Reserved
A field reserved for future use by the Accredited
Standards Committee X9.
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.
Field Field Name Usage Position Size Type
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
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
‘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
Shall be present, unless omitted under clearing
arrangements.
Position
Size
Type
41 - 54
14
ANS Alphameric/special
Immediate Origin Contact Phone Number
The phone number of the contact at the institution that
creates the file.
Usage Conditional
Shall be present, unless omitted under clearing
arrangements.
Position
Size
Type
55 - 64
10
N Numeric
Reserved
A field reserved for future use by the Accredited
Standards Committee X9.
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_Address2 string 70 N Standard address data
Recipient_Address3 string 70 N Standard address data
Recipient_Address4 string 70 N Standard address data
Recipient_Address5 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
information during registration process.
Contact2_Name string 100 N Name of alternate person who can validate account
information during registration process.
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.
BAI2 Standard Field Field Description Field Format
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.
BAI2 Standard Field Field Description Field Format
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.
BAI2 Standard Field Field Description Field Format
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
BAI2 Standard Field Field Description Field Format
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.
BAI2 Standard Field Field Description Field Format
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.
BAI2 Standard Field Field Description Field Format
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.
BAI2 Standard Field Field Description Field Format
Record Code 98
Group Control Total Sum of all the “Amount” fields in this group Default value is positive
Includes the sign “+” and “-“ for the
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.
BAI2 Standard Field Field Description Field Format
Record Code 99
File Control Total Sum of all group totals in this file Default value is positive
Includes the sign “+” and “-“ for the
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
retained for 2 years
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
retained for 7 years
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.