Transmission Toolkit. Copyright 2009 KeyCorp All rights reserved.

Transcription

1 Transmission Toolkit Copyright 2009 KeyCorp All rights reserved.

2 Contents I. General Transmission Overview I - 1 II. III. IV. Implementation and Service Information A. Responsibilities II. A-1 B. Implementation Process II. B-1 C. Post Implementation II. B-1 Transmission Options A. Overview III. A-1 B. KTT Web Based File Transfer III. B-1 i. Requirements III. B-1 ii. Send/Receive Instructions III. B-2 iii. Report Instructions III. B-8 C. Encrypted File Transfer III. C-1 i. FTP w/ PGP or TLS III. C-1 ii. AS-2 III. C-2 Transmission Products and Services A. ARP IV. A-1 B. ACH IV. B-1 C. Batch Wire Transfer IV. C-1 D. EDI IV. D-1 E. BAI2 IV. E-1 F. Lockbox IV. F-1 i. Lockbox data transmission IV. F-1 ii. Lockbox image transmission IV. F-7 G. DDA Return Items IV. G-1 H. Integrated Receivables IV. H-1 V. Appendix A. Contact List V. A-1

3 I. General Transmission Overview

4

5 I. General Transmission Overview Electronic Transmissions provide clients with an opportunity to automate and streamline the delivery and receipt of information reporting and payment related files as opposed to manually entering payment data, or manually retrieving information reporting data. KeyBank provides both attended and unattended file delivery services and supports a variety of popular industry accounting packages. This service provides a simple and secure method for processing and/or retrieving files from a designated mailbox at Key. There are two standard methods utilized to send and/or retrieve data: 1. Key Total Treasury (KTT) Web-Based File Transfer 2. Encrypted File Transfer We recommend electronic file transmissions via either one of our Internet based methods: encrypted file transfer with PGP Encryption or Key Total Treasury File Transfer. Each alternative is described in more detail in Section III. The following types of files can be sent to KeyBank: ACH NACHA Files ARP Check Issue Files EDI Files Batch Wire Transfer Files KeyBank can send the following types of files to clients: ACH Returns and Notification of Change Files BAI2 File (Previous Day and Intraday) Files DDA Returned Items Files (data and/or images) EDI Files including EDI 822 Account Analysis Files Lockbox Detail Information Files Lockbox Image files ARP Account Reconcilement Files Please Note: KeyBank can also send and receive Image cash letter files. Due to resources and equipment required by clients, along with highly technical industry specifications, clients interested in this service will receive separate documentation from their Cash Management Sales Officer. I - 1

6 Transmission Product List Product/Service Account Reconcilement (ARP) Account Reconcilement (ARP) - Paid Check Images ACH Payments Wire Transfer Services EDI BAI2 Reports Lockbox Data Lockbox Images Returned Item Images Transmission Methods Supported Browser Based File Transfer: KTT File Transfer Encrypted File Transfer [Secure File Transfer(SFT)] Encrypted File Transfer [Secure File Transfer (SFT)] Browser Based File Transfer: KTT File Transfer Encrypted File Transfer [Secure File Transfer (SFT)] Browser Based File Transfer: KTT File Transfer Encrypted File Transfer [Secure File Transfer (SFT)] Encrypted File Transfer [Secure File Transfer (SFT)] Browser Based File Transfer: KTT File Transfer Browser Based File Transfer: KTT File Transfer Encrypted File Transfer [Secure File Transfer (SFT)] Encrypted File Transfer [Secure File Transfer (SFT)] Browser Based File Transfer KTT File Transfer I - 2

7 II. Implementation and Service Information

8

9 A. Responsibilities The procedure for setup with KeyBank s standard transmission services consists of three phases: 1) communications testing, 2) applications testing, and 3) production mode follow-through. Operational and technical contacts from both parties will establish the communication link to their satisfaction to ensure network communication is successful. The client will then collaborate with our operational areas to test and validate file formats. Once in production, the initial transmission will be verified for completeness. KeyBank will not supply any codes or programs other than the parameters that are necessary for interaction with the Bank s transmission platform(s). It is the client s responsibility to be able to interface with KeyBank s file transfer system. Prior to the request for transmission services: 1. Clients must meet all hardware and software specifications described in this toolkit. If any of the hardware and/or software specifications cannot currently be supported by the client, clients may request a technical review session with Key Bank s Technical Support Team by calling the Transmission Hotline at Clients must have the appropriate staff (technical or otherwise) available to work with KeyBank to establish communication links, test file formats, and run validity checks. 3. Clients must create test files according to the appropriate formats. Please refer to Section IV for samples. This requirement applies to clients that will be sending files to KeyBank for processing. Any questions regarding the creation of test files can be directed to the transmission Technical Support Team by calling the Transmission Hotline at Clients internal applications must be capable of accepting files from KeyBank. Please refer to Section IV for sample formats. This requirement applies to clients receiving files from KeyBank. Please contact your Fulfillment Support Transmission Specialist (FSTS) at with any questions regarding the receipt of files. Requesting Transmission Services: 1. Your Cash Management Sales Officer will work with you to determine which method of transmitting data will best suit your needs. 2. The client will complete the Transmission Set Up Request Form. Please refer to the Appendix for a copy of this form. A sample form has also been included at the end of this section. 3. Once all the forms have been completed and submitted to your Cash Management Sales Officer, the implementation process will begin. II. A- 1

10 B. Implementation Process 1. After the transmission setup forms and all necessary agreements have been received, the technical contact for your company will receive an notifying them to expect a call the following business day. A copy of this toolkit will be included with the . Sections of the toolkit that should be reviewed prior to the call will be identified. 2. A KeyBank Transmission Specialist will call the technical contact. During the call, the Transmission Specialist will verify the information on the setup form and discuss the following components of the implementation process: a. Client commitment, responsibilities, and scheduling b. Formatting requirements c. Submitting and retrieving test files Any questions and concerns will also be addressed during the call. 3. After the call, you will be ed your mailbox ID and sign on instructions. 4. During the initial set-up phase, a process called the handshake takes place. This is the initial communication test between KeyBank and the client. This test establishes that the client can communicate electronically with KeyBank. It is done before a test file is sent or downloaded. 5. If the client will be retrieving files from KeyBank, KeyBank Operations will load a test file into the mailbox system after the handshake process has been completed and verified. The client will need to download and examine the file to ensure that it meets defined requirements. KeyBank must receive confirmation from the client that the downloaded file is satisfactory before transmission services begin. 6. KeyBank will work closely with your technical resources during the testing and approval phase. Clients MUST make themselves available to work with KeyBank during the transmission setup and testing process. The start of service(s) may be delayed until the testing cycle is complete. 7. Depending on the availability of your technical resources and the validity of the test file(s), completion of the entire process can take between three to six weeks. C. Post Implementation 1. Once testing is complete and the client confirms that the service is setup correctly, the client is moved from the test environment to the production environment. Once the client has been moved to the production environment they must use the same format for all files transmitted to the bank. 2. There is no limit on the number of files that clients can send per day to KeyBank. Depending on the service, files will be processed as they are received or the new file(s) will be appended to the original file and the entire file will be processed during nightly batch processing. 3. Multiple accounts can be sent in the same file as long as they are in the same processing region (contact your Cash Management Sales Officer for details). If the accounts are from different banks within that region, then II. B- 1

11 the files must include the bank number in the record layout. (These requirements will be discussed in detail during testing.) 4. Clients should not alter or add additional information, such as another account, to their file without notifying KeyBank. Proper procedures must be followed in order to ensure that all accounts are correctly setup, in the same layout, and appropriately formatted. 5. KeyBank cannot assist with correcting files due to a client s software problem. The client must utilize their internal technical support or contact the software vendor to address and resolve issues. 6. Once in production: All Communication Issues should be directed to the Transmission Hotline at All Application Issues (incorrect file, wrong format, etc.) should be directed to KeyBank s Corporate Client Services at For Clients using the Key Total Treasury application for file transfer should contact Commercial and Business Banking Center Internet Group at Please refer to the Contact List in the Appendix for additional numbers. 7. Clients performing any upgrades to hardware or software that is used for transmissions must contact the Transmission Hotline to schedule preproduction testing to make certain the client upgrade will not affect transmission communications and/or prevent production files from being sent and/or received. Please allow a minimum of one business week prior to implementation for testing to be performed. II. B- 2

12 III. Transmission Options

13 A. Overview KeyBank offers two transmission options: 1. Browser based file transfer: KTT File Transfer Module 2. Encrypted File transfer with PGP encryption (Secure File Transfer SFT) All Transmission channels are available 24 hours a day / seven days a week. Please refer to the product grid on page I-2 for more information on which services can be supported by the transmission options listed above. Deadlines for sending files to be processed: Type Time ACH 8:00 P.M. ET* EDI 2:30 P.M. ET ARP 11:00 P.M. ET Batch Wire 5:30 P.M. ET *Please note: ACH files can be sent up until 8:00 P.M. ET; however, files received after 5:00 P.M. ET that will be processed on the next business day will be assessed a late fee. Times after which files can be retrieved: Type ACH Returns EDI Return Items BAI2 Intraday BAI2 Previous Day (ME, NH, VT, NY, OH, IN, MI) ARP BAI2 Previous Day (CO, UT, ID, OR, WA) BAI2 Previous Day (AK) Lockbox All times are local to site Time 8:00 A.M ET 9:00 A.M. ET 10:30 A.M. ET 11:30 A.M. ET 8:00 AM - Cleveland and Cincinnati only 12:00 Noon All sites except Buffalo and Denver 3:00 PM All sites except Buffalo EOD All sites III. A- 1

14

15 B. KTT Web-based File Transfer The Key Total Treasury Internet File Transfer module allows clients to upload or download data files to/from KeyBank s transmission platform using a PC and Internet browser. KTT is a Web-based system, so there s no need to use special software. Clients can access Key Total Treasury from any Internet-enabled PC. For optimal performance, we advise clients that they should use only versions of Browsers and Operating Systems that are currently supported by the manufacturer. This does not mean that older versions of Browsers and Operating Systems will not work with KTT; it means that they may not work as well, or as efficiently, or certain functions may not operate as intended. To determine compatibility, a technical review may be arranged by contacting Key Total Treasury s CBBC Team at This service also reports the status of data transfers. Retrieved files are available for a period of four days after the date of creation. Files that are not retrieved are available for 45 days. (Files that are more than five days old are removed at 2:00 A.M. ET the day after they are retrieved.) System Requirements: Processor: 486 or higher RAM: 32 MB or higher Communication Method: 28.8 Modem or higher (Key recommends DSL, cable, T1 or T3 lines) Encryption: Must support 128-bit Secure Socket Layer (SSL) Encryption Secure Port: 443 Non-secure Port: 80 File Size: Smaller than 10 MB Protocol: HTTPS Data Characteristics: All data must be provided in appropriate formats provided within this toolkit III. B- 1

16 Send/Receive Instructions: The following steps will be followed to send and/or retrieve files. These steps will also be utilized in the implementation phase during testing. During testing, users will select Test File Transfer in step 2d. instead of selecting File Transfer. Step 1: Connect to the Internet Step 2: Log into Key Total Treasury a. Go to b. Click on the Corporate tab Please note: Actual website screens may be updated from time to time. III. B- 2

17 c. Enter your User ID and password in the Key Total Treasury section. (This information will be provided to you in a separate mailing.) Please note: Actual website screens may be updated from time to time. III. B - 3

18 d. Click on the File Transfer module tab within KTT. Please note: Actual website screens may be updated from time to time. III. B- 4

19 e. Select File Transfer Please note: Actual website screens may be updated from time to time. III. B- 5

20 f. Select the type of file that you wish to send/retrieve. g. Enter your mailbox ID along with the batch ID and the appropriate file (last two steps required only if sending files). Only required for sending files Please note: Actual website screens may be updated from time to time. III. B- 6

21 h. Select send to upload data or select view to download files. Depending on the function selected, you will be provided with a confirmation screen when the transfer is complete or a list of downloadable reports. Please Note: files that are formatted incorrectly or otherwise invalid will still trigger a confirmation notice. Please view the File Transfer History report to verify the receipt of a file. Please note: Clients may choose the time they wish to send and/or receive data from KeyBank. Please note: Actual website screens may be updated from time to time. III. B- 7

22 Report Instructions: On KTT, clients can view status and history reports related to data transfers performed through Key Total Treasury. Each report contains information about the data transfer itself, including: User, Date/Time, File Name, Batch ID, Status, File Type, File Size, and Direction (sent or received). The History Report contains a list of all file transfers for a rolling 12 month period. The Status Report contains a list of files along with the associated status/process of the transfer. Both reports can be accessed from the File Transfer module on KTT. In order to view the status report, clients will have to enter the appropriate mailbox ID number. Please note: Actual website screens may be updated from time to time. III. B- 8

23 C. Encrypted File Transfer This service allows clients a simple, attended or unattended method for processing and/or retrieving files from Key. Once files are retrieved, they are removed from the system. Files that are not retrieved are available for 60 days. There are two standard methods that we employ to send and/or retrieve data: 1. FTP with PGP or TLS 2. AS-2 PGP, TLS, and AS2 enable information transmitted over public and private global networks to be digitally signed, secured, and nonrepudiated. FTP KeyBank will only setup authenticated and encrypted FTP connections. FTP file transfers can occur in two ways: using our FTP Server or using a trading partner s FTP Server. We prefer that trading partners connect to our FTP Server to place/retrieve files. This gives us greater control over the connection. The options for encrypting FTP traffic are TLS or PGP. Pretty Good Privacy (PGP) is a computer program which can be used to encrypt the payload (the file being transferred) so no one but the intended recipient can read it. PGP encryption occurs prior to sending the file. The system that receives the file must have the corresponding PGP key to successfully decrypt the file. Transport Layer Security (TLS) is used to encrypt the traffic over the network and ensures privacy between communicating applications and their users. TLS can only occur if both the FTP Client and the FTP Server support TLS/SSL. A valid server certificate is required on the FTP Server (or FTP Proxy). TLS is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol. The TLS Record Protocol provides connection security with an encryption method. The TLS Handshake Protocol allows the parties to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before data is exchanged. A TLS handshake occurs at connection time to establish the TLS connection. Specific FTP Configuration Plans Enable TLS, but do not require (force) TLS on the FTP connection (some trading partner s may not support TLS) Authentication required on FTP connection (no anonymous access) Encryption of the payload file with PGP is required for those trading partners who cannot support TLS III. C- 1

24 AS2 AS2 is a real-time technology that provides security and encryption around the HTTP packets. AS2 file transfer is now used by many retail businesses. It has the advantage of providing built-in security features, such as support for digital signatures and encryption. AS2 specifies the means to connect, deliver, validate, and reply to (receipt) data in a secure and reliable way. Messaging features include support for MDN (Message Disposition Notice) to inform the sender of the success or failure of the file transfer. AS2 trading partners can be authenticated by the HTTP Reverse Proxy Server (SecureLink) and/or by digitally signing the message. Specific AS2 Configuration Plans HTTP/S required Support S/MIME (default), Support digital signing of AS2 messages Enable basic authentication (username) for AS2 Relay in the DMZ Support digital signing of AS2 messages Enable basic authentication (username) for AS2 Relay in the DMZ III. C- 2

25 IV. Transmission Products and Services

26

27 A. Account Reconcilement (ARP) Overview KeyBank s ARP service helps to expedite your internal reconcilement process by providing you with a report of your paid checks, including: serial number, dollar amount, and date, along with any stop payments. Our full service also provides cancelled checks, paid exceptions, echeck/ach items, and outstanding checks (unpaid). KeyBank also provides payee verification (payee positive pay) as an added layer of protection. This service compares the payee information on items presented for payment to the issue data that you provide to us. Items that do not match the issue file are presented for your review. ARP Guidelines Clients should submit their file of issued checks as soon as possible after checks are issued. For Positive Pay processing, the deadline is 11:00 P.M. ET on the day prior to the physical distribution of checks (this includes manually issued checks). Clients are responsible for validation of any Paid No Issue items on their Reconcilement as a result of an incomplete or missing issue file. Clients can manually enter Issue or Cancel information on the Account Management Module on KTT by utilizing the Check Issue Maintenance function. Checks that are manually added after the period-end reconciliation has been completed will be added to the next month s reconciliation. Clients should complete these manually added items by the last day of their statement cycle. Clients will need to use the file date on all Canceled and Voided items, as using the issue date will change the Previous Outstanding Balance. Clients will automatically be granted access to the Daily Audit Listing Report on KTT. This report shows all Issues and Cancels on the previous day s file. This report will be available for clients to review on KTT after 9:00 A.M. ET. In the event that an incorrect file was sent to KeyBank, you will need to have the file backed out. Please send an to ARP_Transmissions@KeyBank.com for assistance with backing out the file. Please make sure that you include your name and phone number in the with the subject line Need File Assistance. An ARP associate will then call to assist you. IV. A- 1

28 Clients that are not able to create positive pay files according to KeyBank s standard formats can utilize our File Translator Tool to create their Positive Pay files. Please review the section below for further information. KTT WBFT clients: Please note that the connectivity confirmation only indicates that a file has been received by KeyBank; it does not validate the contents of the file. File Formats ARP Transmission Input Format Record Format: EBCDIC or ASCII* Block Size: 8000 Record Length: 80 FIELD Column # BEGIN END FIELD DESCRIPTION FORMAT Region Code (unused) Blank or Account Number Numeric, Zero-Filled, Right Justified Serial Number/Check Number Numeric, Zero-Filled, Right Justified Date YYYYMMDD Amount Numeric, Zero-Filled, Right Justified, no decimal point Void Character C if void item, otherwise blank THE FOLLOWING FIELD IS OPTIONAL: Additional Data Alpha or Numeric *If an ASCII format is used, the receiving mainframe will convert the file to EBCDIC format through a protocol converter. Report-type formats are not acceptable. Example: < Account >< Serial > < Number >< Number >< Date >< Amount > C void item IV. A- 2

29 Payee Transmission Format Specifications # BEGIN END FIELD DESCRIPTION FORMAT Region Code (unused) Blank or Account Number Numeric, Zero-Filled, Right Justified Serial Number/Check Number Numeric, Zero-Filled, Right Justified Date CCYYMMDD Amount Numeric, Zero-Filled, Right Justified, no decimal point Void Character C if void item, otherwise blank THE FOLLOWING FIELD IS REQUIRED* Additional Data Alpha or Numeric Payee line 1* Alpha or Numeric as it appears on the check Payee line 2* Alpha or Numeric - as it appears on the check Filler Spaces *=Required Example: < ACCOUNT # >< SERIAL #> < DATE ><AMOUNT> < PAYEE LINE 1> <PAYEE LINE 2> CRAIG W CARNAHAN CHERYL A CARNAHAN DOUGLAS R AUSDEMORE DONNA R AUSDEMORE VLADIMIR V POLYSHCHUK VALERIE V POLYSHCHUK M DOUGLAS GURLEY LAURA GURLEY Payee Line 1 is required for Payee Positive Pay. Payee Line 2 is only required when a 2 nd Payee exists. The Additional Data field is used to input any information that is pertinent to your individual company to help identify payees, such as vendor name, employee ID, etc. Please note the Additional Data will show on your ARP Reconcilement reports. IV. A- 3

30 ARP Transmission Output Format (Paid Items only) Record Format: EBCDIC Block Size: 9990 Record Length: 90 FIELD COLUMN # BEGIN END FIELD DESCRIPTION FORMAT Account Number Numeric, Zero-Filled, Right Justified Serial Number/Check Number Numeric, Zero-Filled, Right Justified Amount Numeric, Zero-Filled, Right Justified, no decimal point Date MMDDYY THE FOLLOWING FIELDS ARE OPTIONAL: Issue Date MMDDYY Sequence Number* Numeric Additional Data Alpha Example: < Account >< Serial > < Number >< Number ><Amount>< Date> The 3890 Sequence Number is the sequence number of your paid check. Additional Data Field fields are used to relay any information that is pertinent to your individual company to help identify payees, such as vendor name, employee ID, etc. IV. A- 4

31 ARP Transmission Output Format (Complete File) Record Format: EBCDIC Block Size: 9990 Record Length: 90 FIELD COLUMN # BEGIN END FIELD DESCRIPTION FORMAT Account Number Numeric, Zero-Filled, Right Justified Serial Number/Check Number Numeric, Zero-Filled, Right Justified Amount Numeric, Zero-Filled, Right Justified, no decimal point Paid Date MMDDYY Issue Date MMDDYY Item Indicators Alpha Item Indicators are as follows: C- Cancel S- Stop P PNI Checks are paid but not issued in ARP. R - Reconciled* O- Outstanding *R- Reconciled is a matched, paid item IV. A- 5

32 MICR Quality Test Checks for Positive Pay Clients will need to send a test file that matches the test checks. The service level for testing checks is seven business days from the receipt of the checks. Any failures identified during testing will be communicated to you by a phone call, and then followed-up with an notification. Rejections will include specific corrections and recommendations that are required before newly created checks can be re-tested. If failures occur during testing, a new seven business day cycle will be required for additional testing. Changes to preprinted check stock must be tested and approved before production. MICR Quality Test Checks for Payee Name Verification (PNV) Positive Pay Clients will need to send a test file that matches the test checks. The service level for testing checks is seven business days from the receipt of the checks. Any failures identified during testing will be communicated to you by a phone call, and then followed-up with an notification. Rejections will include specific corrections and recommendations that are required before newly created checks can be re-tested. If failures occur during testing, a new seven business day cycle will be required for additional testing. Payee Name Verification Best Practices and Recommendations Font Type Times New Roman Courier Verdana Univers Tahoma Albertus Bookman Zurick Font Size 10 to 24 points IV. A- 6

33 Format Specifications These recommendations will allow for appropriate spacing between individual letters allowing your Payee line portion of the check to read properly. Set Pitch proportionate to Font Use Upper-case Alphabetic Characters on your file and check Do not use tags (decorative or script font) that could be misinterpreted or act as connectors to the next character. (An example of a font using tags,anne SMITH) Do not use Bold or Italic effects Do not use leading or trailing asterisks (****) Do not use extraneous print in the Recognition Area Do not use a Dot Matrix printer Payee Line Format Spacing Default font spacing must have a clear separation between individual characters and between lines of text. Minimum Separation between Payee lines of text is inches Printing must be dark enough for a Minimum Contrast Signal of 0.60 Check Background Payee Data The area of the check in which the Payee Name and Address is printed must be white, or printed with a light pastel color of Print Contrast signal.30 or less and must extend at least.25 inches around the printing. There should be no other information, lines, symbols, or marks appearing in this region. This includes any type of security features added to check background. IV. A- 7

34 Payee Format Specifications Up to two lines of Payee Name information may be printed on the check for Payee data review. Up to 75 characters may be printed per line. Character Match The format of the Payee Name information printed on the check must exactly match, character by character, the format of the payee name information submitted in the Issue list.. Recognition Coordinates one set per Account Location of the Payee Name(s) on the check and the Payee Font Type cannot vary for a given Routing-Transit/Account Number combination as the Bank is only able to define one set of coordinates per account. If you are an existing KeyBank Full ARP service client, payee verification begins at implementation date. We cannot process a history file of payee data, because that issuance information is already in our system. IV. A- 8

35 KeyBank File Translator You can create a data file in your accounting application and import the data into the File Translator software. The check issuance file will be formatted accordingly to KeyBank s standards. This file can then be transferred to KeyBank via Transmission or WBFT via Key Total Treasury.. FAQs 1. What happens if transmission testing is not completed? Completing testing and sending files in a timely manner reduces the number of exception items that clients must review and then pay or reject. 2. If I send a bad file, can I just resend a corrected file? No. Clients need to contact the ARP Operations mailbox (Account_Recon@Keybank.com) or call the assigned reconciler so that the bad file can be backed out of the ARP software. If the bad file is not backed out, the second file sent will reject because the check numbers are the same. 3. I have my KTT confirmation, but I don t think the file was received because Positive Pay exceptions are showing. What s wrong? The file confirmation on KTT is a confirmation of connectivity. Actual file data cannot be validated until the file updates into the reconciliation software during Key s nightly batch processing. 4. What is the purpose of my mailbox ID? The mailbox ID is your access to process a file on our KTT Web site. If you send a file to an incorrect mailbox ID, it will not process. 5. Why do I have an Audit Listing Report for an account I did not send a file to? The lead account processes all files sent, regardless of the account number. When a file is processed, the total items will show on the lead account and the detail will show on the Audit Report for the account the file was sent to. 6. If I convert from Standard Positive Pay to Positive Pay with Payee Name Verification, do I need to resend outstanding check data with the payee names? No. KeyBank already has the issuance data. Any new data for the same check number will reject. An implementation date will be communicated once testing has successfully been completed. Only items issued after that date will go through the Payee Name Recognition process. IV. A- 9

36 7. When will I start to review Positive Pay Exceptions on KTT? Items will be available for you to view during the testing phase. Contact your Cash Management representative for your service start date. 8. What is the difference between service start date and implementation date? Service state date is the date listed on the Client Service Order that is submitted by sales. The implementation date is the date testing is completed and the file moves into production. IV. A- 10

37 B. ACH Overview Debit and credit ACH transactions can be initiated by sending NACHA formatted files to KeyBank. KeyBank requires that an ACH file sent in through Direct File Origination or web-based file transfer be received no later than 9 p.m. ET one business day prior to the file settlement date. Sending your file in by 2 p.m. ET provides an opportunity for making minor changes to your file (if necessary) while still meeting the 8 p.m. ET deadline. KeyBank (like NACHA) recommends that Payroll files be originated two business days prior to settlement. While most files settle without incident, a two-day origination window provides additional assurance that a posting delay at the receiving financial institution will not impact your employees. Please Note: ACH files can be sent up until 8:00 P.M. ET; however, files received after 5:00 P.M ET that will be processed on the next business day will be assessed a late fee. IV. B- 1

38 File Formats ACH/NACHA-Automated Clearing House/National Automated Clearing House Association Record Layout Sequence (NACHA format) Position 1 FILE HEADER RECORD Position 5 BATCH HEADER RECORD 1ST ENTRY DETAIL RECORD - ONE PER FILE - FIRST LOGICAL RECORD - ONE PER BATCH Position 8 Position 6 2ND ENTRY DETAIL RECORD ETC... LAST ENTRY DETAIL RECORD BATCH CONTROL RECORD BATCH HEADER RECORD - ONE PER BATCH 1ST ENTRY DETAIL RECORD Position 6 ETC. LAST ENTRY DETAIL RECORD Position 8 Position 9 BATCH CONTROL RECORD ETC. FILE CONTROL RECORD ONE PER FILE - FIRST LOGICAL RECORD FILL USED TO COMPLETE LAST PHYSICAL BLOCK IV. B- 2

39 ACH Codes SERVICE CLASS CODES 200 ACH Entries Mixed Debits and Credits 220 ACH Credits Only 225 ACH Debits Only 280 ACH Automated Accounting Advices STANDARD ENTRY CLASS CODES CCD Cash Concentration or Disbursement CIE Customer Initiated Entries CTX Corporate Trade Exchanges MTE Machine Transfer Entries POP Point of Purchase Entry POS Point of Sale PPD Prearranged Payments and Deposits RET Automated Returns RCK Re-presented Check Entry SHR Shared Network Transaction TEL Telephone Initiated Entry TRC Truncated Entries TRX Truncated Entries (w/addenda) WEB Internet Initiated Entry XCK Destroyed Check Entry TRANSACTION CODES Demand Credit Records (for checking, NOW, and share draft accounts) 20 Reserved 21 Automated Return or Notification of Change for original transaction code 22 or Automated Deposit Checking account credit entry 23 Prenotification of Demand Credit Authorization (non-dollar) 24 Zero dollar with remittance data (CCD, CTX) Demand Debit Records (for checking, NOW, and share draft accounts) 25 Reserved 26 Automated Return or Notification of Change for original transaction code 27 or Automated Payment Checking account debit entry Prenotification of Demand Debit Authorization (non-dollar) Zero dollar with remittance data (CCD, CTX) Savings Account Credit Records 30 Reserved 31 Automated Return or Notification of Change for original transaction code 32 or Automated Deposit Savings account credit entry 33 Prenotification of Savings Credit Authorization (non-dollar) 34 Zero dollar with remittance data (CCD, CTX) Savings Account Debit Records 35 Reserved 36 Automated Return or Notification of Change for original transaction code 37 or Automated Payment Savings account debit entry 38 Prenotification of Savings Debit Authorization (non-dollar) 39 Zero dollar with remittance data (CCD, CTX) Loan Account Credit Records 51 Automated Return or Notification of Change for original transaction code 52,53, or Automated Loan Account Deposit (Credit) 53 Pre-notification of Loan Account Credits Authorization (non-dollar) 54 Zero dollar with remittance data (for CCD & CTX only) Loan Account Debit Records 55 Automated Loan Account Debit (Reversals Only) 56 Automated Return or Notification of Change for original transaction code 55 ADDENDA TYPE CODES 02 Point of Sale Entry (POS), Shared Network Transaction (SHR), or Machine Transfer Entry (MTE) terminal location description. 05 Special Addenda Information (Addenda Record(s) apply to CCD, CIE, PPD and CTX entries and TRX 98 Automated Notification of Change 99 Automated Return Entry ADDENDA RECORD INDICATOR 0 No Addenda Record(s) follow 1 Addenda Record(s) follow ORIGINATOR STATUS CODES 1-- This code identifies the Originator as a depository financial institution which has agreed to be bound by the NACHA 2-- This code identifies the Originator as a federal government entity or agency not subject to the NACHA rules. IV. B- 3

40 File Header Record (NACHA format) FIELD # FIELD POSITION INFO 1 01 NNNNNNNNNN NNNNNNNNNN YYMMDD HHMM A KEYBANK XYZ CORPORATION xxxxxxx Field # Field Position Field Length Field Description Definition RECORD TYPE CODE FILE HEADER IDENTIFIER - MUST BE <1> PRIORITY CODE FIXED INFORMATION-MUST BE <01> IMMED. DESTINATION # *(1)* KEYBANK S PROCESSING BANK R/T # NOTE: FIELD RIGHT JUSTIFIED, BLANK FOLLOWED BY # IMMEDIATE ORIGIN # *(1)* ORIGINATOR #-SHOULD BE TAXPAYER ID# OF COMPANY. NOTE: FIELD RIGHT JUSTIFIED, BLANK FOLLOWED BY # TRANSMISSION DATE DATE OF FILE CREATION-FORMAT <YYMMDD> TRANSMISSION TIME TIME OF FILE CREATION-FORMAT <HHMM> FILE ID MODIFIER ALPHANUMERIC CHARACTER TO UNIQUELY IDENTIFY MULTIPLE FILES THAT WERE CREATED ON THE SAME DAY RECORD SIZE RECORD SIZE-MUST BE <094> BLOCKING FACTOR BLOCKING FACTOR-MUST BE <10> FORMAT CODE FORMAT CODE-MUST BE <1> DESTINATION NAME *(1)* PROCESSING BANK NAME ORIGIN NAME *(1)* ORIGINATORS NAME-MUST BE NAME OF COMPANY REFERENCE CODE OPTIONAL FIELD-AVAILABLE FOR COMPANY S INTERNAL USE *(1)* BANK MUST BE NOTIFIED PRIOR TO MAKING ANY CHANGES TO THIS FIELD (NOTE: Routing and Transit Number is abbreviated as R/T # in this and subsequent record layouts.) IV. B- 4

41 Company Batch Header Record (NACHA format) FIELD # FIELD POSITION INFO 5 2NN XYZ CORPORATION XXXXXXXXX NNNNNNNNNN PPD Entry Type xxxxxx YYMMDD 1 NNNNNNNN Field # Field Position Field Length Field Description Definition RECORD TYPE CODE BATCH HEADER IDENTIFIER - MUST BE <5> SERVICE CLASS CODE TYPE OF ACH ENTRIES-200 = MIXED DEBITS AND CREDITS 220= CREDITS ONLY 225 = DEBITS ONLY COMPANY NAME *(1)* COMPANY NAME - WILL APPEAR IN THIS FORM ON RECIPIENTS CHECKING/SAVINGS ACCOUNT STATEMENT CO. DISCRETIONARY DATA FIELD AVAILABLE FOR COMPANY USE CO. IDENTIFICATION *(1)* COMPANY NUMBER 1 FOLLOWED BY 9 DIGIT CO TAX ID # OR FOR EACH DDA, A UNIQUE NUMBER FOLLOWED BY A COMPANY ASSIGNED ID STD. ENTRY CLASS CODE *(1)* ENTRY CLASS (SEE PAGE IV. B-3) CO. ENTRY DESCRIPTION *(1)* TRANSACTION TYPE - WILL APPEAR IN THIS FORM ON RECIPIENTS CHECKING/SAVINGS ACCOUNT STATEMENTS (i.e., <PAYROLL><PENSION><PAYMENTS>` CO. DESCRIPTIVE DATA OPTIONAL DATE INFORMATION - COMPANY USE EFFECTIVE ENTRY DATE DATE OF SETTLEMENT OF TRANSACTIONS - FORMAT <YYMMDD> CREDIT ENTRIES SHOULD HAVE A 1-2 DAY SETTLEMENT DATE IN ADDITION TO THE BANK PROCESSING DAY. DEBIT ENTRIES SHOULD HAVE AN EFFECTIVE DATE OF ONE DAY IN ADDITION TO THE BANK PROCESSING DAY. BLANK OR INVALID EFFECTIVE ENTRY DATES WILL BE POPULATED WITH THE FIRST BUSINESS DAY FOLLOWING THE PROCESSING DAY SETTLEMENT DATE MUST BE BLANK (FOR BANK USE ONLY) *(1)* BANK MUST BE NOTIFIED PRIOR TO MAKING ANY CHANGES TO THIS FIELD *When using multiple DDA Accounts, the number in position 41 can change. IV. B- 5

42 Field # Field Position Field Length 1 Company Batch Header Record (NACHA format)- Continued Field Description ORIGINATOR STATUS CODE Definition BANK STATUS MUST BE <1> *(1)* PROCESSING BANK R/T # = SHOULD BE ORIGINATION ID KEYBANK S R/T # BATCH NUMBER SEQUENTIAL NUMERIC BATCH # - STARTING WITH < > *(1)* BANK MUST BE NOTIFIED PRIOR TO MAKING ANY CHANGES TO THIS FIELD *When using multiple DDA Accounts, the number in position 41 can change. IV. B- 6

43 FIELD # FIELD POSITION INFO Field # NN Field Position RRRRTTTT C Entry Detail Record (NACHA format) $$$$$$cc AAAAAAAAAAAAAAAAAA Field Length Field Description Definition NNNNNNNNNNNNNNN RECORD TYPE CODE ENTRY DETAIL IDENTIFIER - MUST BE <6> TRANSACTION CODE TYPE OF TRANSACTION - SEE PAGE IV. B ROUTING/TRANSIT NUMBER R/T # OF RECIPIENT S FINANCIAL INSTITUTION R/T # CHECK DIGIT R/T # CHECK DIGIT OF RECIPIENT S FINANCIAL INSTITUTION INDIV. ACCOUNT NUMBER RECIPIENT S ACCOUNT NUMBER - LEFT JUSTIFIED NUMBERS <0-9> AND HYPHENS <-> ONLY, OMIT SPACES AMOUNT AMOUNT OF TRANSACTION - MUST BE NUMERIC INDIVIDUAL ID # NUMBER BY WHICH RECIPIENT IS KNOWN TO THE COMPANY INDIVIDUAL NAME RECIPIENT S NAME DISCRETIONARY DATA OPTIONAL FIELD - AVAILABLE FOR COMPANY S INTERNAL USE ADDENDA INDICATOR ADDENDA RECORD INDICATOR - MUST BE <0> IF NO ADDENDA TRACE # FIRST 8 CHARACTERS SHOULD BE THE FIRST 8 DIGITS OF KEYBANK S R/T #, REMAINING 7 MUST BE SEQUENTIAL NUMBERS ASSIGNED BY COMPANY IV. B- 7

44 Company Batch Control Record (NACHA format) FIELD # FIELD POSITION INFO 8 2NN $$$$$$$$$$$$$cc $$$$$$$$$$cc NNNNNNNNNN NNNNNNNN Field # Field Position Field Length Field Description Definition RECORD TYPE CODE BATCH CONTROL IDENTIFIER - MUST BE <8> SERVICE CLASS CODE *(2)* TYPE OF ACH ENTRIES = MIXED DEBITS AND CREDITS 220 = CREDITS ONLY 225 = DEBITS ONLY ENTRY/ADDENDA COUNT # OF RECORDS IN BATCH - MUST BE UNSIGNED NUMERIC ENTRY HASH ACCUMULATION OF ROUTING/TRANSIT #s FROM ENTRY DETAIL RECORDS (FIELD 3) NOTE: TRUNCATE HIGH ORDER DIGITS BEYOND 10 CHARACTERS TOTAL DEBITS $ AMOUNT AMOUNT OF DEBITS IN BATCH - MUST BE UNSIGNED NUMERIC NOTE: IF NO DEBIT $ MUST BE < > TOTAL CREDITS $ AMOUNT AMOUNT OF CREDITS IN BATCH - MUST BE UNSIGNED NUMERIC NOTE: IF NO CREDIT $ MUST BE < > CO. IDENTIFICATION *(2)* COMPANY NUMBER - 1 FOLLOWED BY 9 DIGIT CO Tax ID # OR FOR EACH DDA, A UNIQUE NUMBER FOLLOWED BY A COMPANY ASSIGNED ID RESERVED MUST BE LEFT BLANK RESERVED MUST BE LEFT BLANK ORIGINATION ID *(2)* PROCESSING R/T # - SHOULD BE KEYBANK S R/T # BATCH NUMBER *(2)* SEQUENTIAL NUMERIC BATCH # - STARTING WITH < > *(2)* MUST BE SAME AS BATCH HEADER OF SAME BATCH IV. B- 8

45 File Control Record (NACHA format) FIELD # FIELD POSITION INFO $$$$$$$$$cc $$$$$$$$$$cc Field # Field Position Field Length Field Description Definition RECORD TYPE CODE FILE CONTROL IDENTIFIER - MUST BE <9> BATCH COUNT # OF BATCHES IN FILE - MUST BE UNSIGNED NUMERIC, THE VALUE OF THIS FIELD MUST BE THE SAME AS THE NUMBER OF BATCH HEADER RECORDS IN THE FILE BLOCK COUNT # OF BLOCKS IN FILE - MUST BE UNSIGNED NUMERIC ENTRY/ADDENDA COUNT # OF ENTRY DETAIL RECORDS IN FILE - UNSIGNED NUMERIC ENTRY HASH ACCUMULATION OF ROUTING/TRANSIT #s FROM ENTRY DETAIL RECORDS (FIELD 3) NOTE: TRUNCATE HIGH ORDER DIGITS BEYOND 10 CHARACTERS TOTAL DEBIT AMOUNT AMOUNT OF DEBITS IN FILE - MUST BE UNSIGNED NUMERIC NOTE: IF NO $ MUST BE < > TOTAL CREDIT AMOUNT AMOUNT OF CREDITS IN FILE - MUST BE UNSIGNED NUMERIC NOTE: IF NO $ MUST BE < > RESERVED MUST BE BLANK IV. B- 9

46 Sample ACH Formats Pre-authorized Payment and Deposit Entry (PPD) Entry Detail Record Record Type Code DFI ID # DFI Account number Individual Identification Number Discretionary Data Trace Number Transaction Code Check Digit Amount Individual Name Addenda Record Indicator Cash Collection and Disbursement Entry (PPD) Entry Detail Record Record Type Code DFI ID # DFI Account number Individual Identification Number Discretionary Data Trace Number Transaction Code Check Digit Amount Individual Name Addenda Record Indicator IV. B- 10

47 Corporate Trade Exchange Entry (CTX) Entry Detail Record Record Type Code DFI ID # DFI Account number Identification Number Receiving Company ID# Discretionary Data Trace Number Addenda Type Code Check Digit Amount Number of Addenda Records Reserved Addenda Record Indicator Notification of Change Entry (NOC/COR) Entry Detail Record Record Type Code DFI ID # DFI Account number Individual Identification Number Discretionary Data Trace Number Transaction Code Check Digit Amount Individual Name Addenda Record Indicator IV. B- 11

48 PPD, TEL, WEB Entry Detail Record Record Type Code DFI ID # DFI Account number Individual Identification Number Discretionary Data Trace Number Transaction Code Check Digit Amount Individual Name Addenda Record Indicator Returns Entry Detail Record Record Type Code DFI ID # DFI Account number Individual Identification Number Discretionary Data Trace Number Transaction Code Check Digit Amount Individual Name Addenda Record Indicator IV. B- 12

49 ACH Frequently Asked Questions 1. Can the ACH department assist clients with creating files from their internal software? No. Clients must contact their own IT department or the software vendor for assistance with creating files. 2. How long after a valid test file is sent can a production file be sent? The standard is five business days after a valid test file is received and approved. 3. Can KeyBank accept CTX and CCD standard entry class codes? Yes. CCD transactions with one line of addenda information are accepted. CTX allows multiple lines of addenda information. 4. Do files have to be balanced? No, KeyBank prefers ACH files to be unbalanced. 5. Under what conditions is testing required. When upgrading software Name changes When experiencing Hash total problems 6. What are the different types of Addenda? Free form Tax payments Child Support 7. When are pre-notes required? Clients are required to pre-note with Tax payments IV. B- 13

50

51 C. Batch Wires Overview Batch wire transmissions enable clients to transmit transaction information generated from their internal systems to KeyBank s wire platform. Batches can contain multiple wire types including domestic, international, and internal wires and even drawdowns. The wire transfer instructions are reviewed and released within minutes after receipt of the file. The system also provides an electronic confirmation which can be utilized to automatically update accounting systems. The Batch Wire Service can easily accommodate clients with large volumes of repetitive wires initiated multiple times per day or week. IV. C- 1

52 Sample Batch Data Description *AMT ABC Batch header *FTR NRF FTR Payment, non-repetitive 2FTR DBT=D/ BBK=A/ CITI BNF= COMPANY XYZ OBI= Payment to Invoice 123 /FTR *FTR RPF FTR Payment, repetitive 2FTR DBT=D/ /FTR *FTR NRF DRC Drawdown, non-repetitive 2FTR ORG=D/ ABC COMPANY ACCOUNT Account at another FI DBT=D/ BBK=A/ PROVIDENT BNF= XYZ COMPANY CLEARING ACCOUNT Account name at KeyBank /FTR *FTR RPF FTR Payment, repetitive 2FTR DBT=D/ /FTR *FTR RPF DRC Drawdown, repetitive 2FTR DBT=D/ /FTR *FTR NRFUSD FTR SWIFT transaction 2FTR SWF Send today, value date tomorrow IV. C- 2

53 DBT=D/ BBK=S/001:BKCHCNBJ BNF=D/ Bob the builder -Shanghai, China /FTR *FTR NRFUSD FTR 2FTR SWF DBT=D/ BBK=S/001:BKCHCNBJ BNF=D/ Bob the builder -Shanghai, China /FTR /AMT ABC AMT All of our SWIFT reimbursement paths are built to belong to our bank number 001. All SWIFT IDs should be prefaced with "001:" for best straight-thru processing results SWIFT transaction, multiple credit parties Send today, value date tomorrow All of our SWIFT reimbursement paths are built to belong to our bank number 001. All SWIFT IDs should be prefaced with "001:" for best straight-thru processing results Batch trailers Both records are required IV. C- 3

54 Batch Wire Formats Batch Header Record: Field Name Position Size Description Value for <Batch Name> Record_Type PICX(4) Contains *AMT *AMT Reserved PICX(6) Spaces Spaces Batch_ID PICX(10) Uniquely identifies each batch sent into MTS. The format <source><julien date><batch_sequence> of this field is up to the client but we recommend including the source, date, and sequence number. The source is a three character field assigned by Key Technology Services. Date_Time PIC9(12) YYMMDDHHMMSS Example: Batch_Sequence PIC9(4) Batch sequence within the current day. This number is Example: 0001, 0002, 0003, etc reset to 0001 every morning and each incremental batch increases this value by 1. Used to control duplicate batches. Reserved PICX(8) Spaces Spaces Bank PICX(3) Assigned by Key Bank Spaces unless instructed by KeyBank to use another value Reserved PICX(8) Spaces Spaces Comment PICX(25) Text comment. Example: ABC Company Batch Wires IV. C- 4

55 Funds Transfer Header Record 1: Field Name Position Size Description Value for <Batch Name> Record_Type pic x(4) Contains *FTR. *FTR Batch_Sequence pic 9(4) This field must match the value in the batch header Example: 0001, 0002, 0003, etc record, positions This number is reset to 0001 every morning and each incremental batch increases by 1. Used to control duplicate batches. Item_Sequence pic 9(6) Sequence number of each transaction within this , , , etc. batch. Starts at and each transaction increases by 1. System_Ref pic x(16) System Reference number that uniquely identifies this transaction. This information stays with the transaction history and is displayed in all inquiries, delivery confirmations, or debit confirmations. The <source> <julian date> <batch_sequence> <Item_Sequence> Example: ABC format is completely up to the client. Key Bank recommends that the client populate this field with the batch_id from the batch header record appended by the item_sequence number in this record. Reserved pic x(4) Reserved Spaces Type pic x(2) NR if one-time wire or RP for repetitive transactions. "RP" or "NR" If a client has set up repeats with the wire room, this field indicates this transaction is using a pre-defined repeat specified in the 2FTR record immediately following this record. FX_flag 37 pic x(1) T if foreign currency, else F if US dollars "F" or T Currency_Code pic x(3) Currency ISO value if the client is sending a wire Spaces, USD, or ISO currency code overseas where the beneficiary will be paid in a foreign currency. Spaces default to US dollars. Currencies are limited to those traded by KeyBank. Reserved pic x(3) Spaces Spaces Amount pic 9(12).99 The amount of the transaction in the selected currency. Reserved 59 pic x(1) Spaces Spaces Example: (15 digits including decimal) IV. C- 5