Bank of America Discovery Questions



Bank of America Discovery Questions

July 31, 2001

Dixie Hill, R&D, State Technology Office

850.921.4057

The STO, Research & Development group is seeking immediate information to assist the STO in re-engineering its Internet e-payment architecture. The STO provides an E-mall merchant service and a custom built in-house bridge solution to the CyberCash gateway. STO has the responsibility to provide assistance and facilitate the other customers that are currently using the STO integrated payment API. We seek the immediate opportunity to work with BOA for Internet credit card acceptance. Note: The CIP/eStores interface will replace all need for CyberCash. The RFP response by BOA did not include any provision for CyberCash.

Technology Products, page 5:

• Identify 12 terminal products. Please see attached listing.

• Identify ECR Interfaces & PC products for point of sale. Please see attached listing

• Features and capabilities of each? Please see attached listing.

Question: How can a consolidated backend transaction based GL information (product identifier, transaction #, or GL code) be incorporated across these acceptance methods & products to meet the GL reconciliation and reporting requirement? (Integrated GL reporting solution for all payment acceptance methods) Of the above products, please provide information identifying the technical responsibilities of the State of Florida and contracted service providers to host these products.

Our customized solution to meet the state’s requirements for reconciliation and reporting are currently being addressed with Bank of America Product Management and Metavante. We will provide our detailed approach to meet these needs by the end of September. Our approach is to provide a comprehensive report from the Customer Initiated Payments system that will include all information from the web payments screen.

Page 8, #12. Customer Service:

Question: What is CADRE? (Client Server) software for processing Chargebacks?) Can the charge back information be disseminated to the Agencies? CADRE is an internal chargeback imaging systems that provides the process for Bank of America to manage our bankcard chargebacks. Notification of chargebacks are sent via mail or fax as specified by the Agencies.

Page 9, #15, Technical Plan:

Identifies a Payment Gateway that will provide Web and IVR acceptance methods for credit cards.

Question: Does this include other cards besides MC/Visa, such as AE, Discover? Yes

Question: Is the acceptance of Debit Cards by Web & IVR limited to those that are sponsored by Visa/MC? Yes

Question: Will the Gateway and the IVR support the acceptance of E-Checks? If so, can these methods support the GL (product) information in the acceptance? The Credit Card and ACH gateways are separate and operate independently. CIP supports ACH and the eStores interface will support the Credit Card. The support for GL data will be included in our Reconciliation Solution.

.Also, the eStores (Metavante Corp) is identified as the Payment gateway to facilitate credit cards and IVR via https. An API is defined for communicating with the e-Store Gateway.

Page 11, indicates that all SOF servers or contracted service providers for the state of FL are identified by IP allowing access to the Gateway.

Question: What is the proposed management and business policy to insure that requests for access by IP (server) are authentic, valid and coming from an authorized employee of the State? (i.e. Individual making a request that may have intentions of SOF server masquerading.) Credit Card transactions through CIP/eStores are validated by the IOC_merchant_id using an HTTP_REFERER check. Only those domain or IP addresses that are authorized by the State will be allowed to post transactions. Additionally, since the CIP interface to eStores is hidden and utilizes an in-process connection from CIP to eStores, exposure of the connection to the outside Internet environment is limited and secured by HTTPS.

Security Question: What are BOA’s security requirements for Merchants and state hosted web sites? Will the Merchant Security Guidelines, defined by Visa, be expected/mandated for all merchants and acceptable to BOA? BOA expects compliance with Visa’s CISP requirements.

Page 14, #19 Goals of Deployment

CIP – Customer Initiated Payments. – Collects payments from multiple sources and transfers them to BOA. CIP collects payment, posting, and funds transfer information into a single ACH file. “While the payment is transferred to the Bank, related information, organized the way the State desires, can be transferred to the State or agencies as part of a consolidated transaction detail.”

Question: What is CIP? Customer Initiated Payments. Is it a back end information system that also requires payment system software hosted by the SOF? Is it the repository for the Internet and IVR? No technology details.

In its simplest form, CIP is a payment and information engine. Through CIP, our client’s customers can initiate payment via credit card or ACH customer initiated debit using the voice/touchtone, Internet and POS delivery channels. While CIP can be only used as a standard payment engine, its most valued benefit is the information engine. By using CIP’s front-end payment templates, our client controls the amount of information necessary to reconcile the payment process.

CIP is a Bank of America provided service, built and powered by Metavante. Customer support to our clients will be provided by Bank of America. Bank of America Merchant Services and Global Treasury Management will manage the payment platform and financial (settlement transaction) information reporting.

Page 18, #23 Processing Requirements. – “The consolidation process at the BOA will provide for tracking all transactions to the deposit number of settlement batch.”

Question: Can details be provided on how this is to be accomplished? These details will be provided with our reconciliation and reporting proposal.

Note - The common element identified between the Gateway and the calling web application is the “Confirmation” number. Is it proposed that a join operation using the confirmation # between the two data sets and a deposit number going to be utilized to provide reconciliation/reporting to FLAIR?

There are two forms of reconciliation to this process. One is the reconciliation of the settlement transaction to its appropriate file. We indicate this as “treasury” reconciliation. The second is the reconciliation of individual transactions to each agency/departmental general ledger system. We identify this as “general ledger” reconciliation. While the two are correlated they act independently.

For treasury reconciliation, the SOF will extract a BAI file from Bank of America that will contain information related to settlement transactions. This information can be matched to a merchant and/or ACH settlement file processed through the CIP payment engine. This process will balance the bank account against the total files processed for payment.

For general ledger reconciliation, the SOF will receive a file that contains the individual transactions (both merchant card and ACH) with all of the relevant transactional information; including transaction confirmation number or required data elements. This information can be matched to the appropriate general ledger(s) for the transactions and the order can then be fulfilled.

In the case of the general ledger reconciliation, if a proprietary or other vendor payment template is used, that service will be responsible for providing the SOF detailed transactional information. Bank of America will still continue to provide standard settlement transaction information and a basic merchant card file. However, additional data related to the individual transaction (CIP data) will not be available.

Page 20, #26 Internet – “the State web site must provide all data required for GL reporting to Payment Gateway over the HTTPS connection.“

Question: Can the Payment Gateway track the GL information if it is provided to the existing BOA Gateway? None of the reporting that is part of the end product is supplied by eStores, which is acting only as the Internet Credit Card Payment Gateway. This function will be handled by the CIP component, which acts as the managing hub of all the data exchanged between the respective systems.

This is not a capability in the existing EStores solution based upon the Developers technical guide for web transaction processing. See:

The information within identifies the following: “In addition to the listed fields for submitting a transaction, any merchant defined name/value pairs submitted will be returned in the response string. The additional data will not be stored by eStores Solutions”

Currently, identified are the standard ECML field names. Identifying the GL as additional information in the name/value pairs is of no value because this data will not be stored in the eStores solution. (According to the web site information.) Current information defining the ECML from the web site is as follows:

Table 1. Fields for processing and authorization

|Field Name |Required |Maximum |Description |

| |(Yes/No) |Characters | |

|ioc_merchant_id |Yes* |50 |eStores assigned merchant ID. Unique for each|

| | | |live account. |

| | | |Suggest "hidden" field. |

|ioc_order_total_amount |Yes* |10 |Total amount of transaction to be authorized.|

|ioc_merchant_shopper_id |No |32 |Merchant generated shopper ID. Useful for |

| | | |integration with merchant database and for |

| | | |eStores search information. Suggest "hidden" |

| | | |field. |

|ioc_merchant_order_id |No |32 |Merchant generated order ID. Useful for |

| | | |integration with merchant database and for |

| | | |eStores search information. Suggest "hidden" |

| | | |field. |

|ecom_billto_postal_name_first |No |50 |First name of cardholder. |

|ecom_billto_postal_name_last |No |50 |Last name of cardholder. |

|ecom_billto_postal_street_line1 |Yes |50 |Cardholder's billing address. |

|ecom_billto_postal_street_line2 |No |50 |Cardholder's billing address (line 2). |

|ecom_billto_postal_city |No |50 |Cardholders billing city. |

|ecom_billto_postal_stateprov |No |30 |Cardholder's billing state or province. At |

| | | |least two characters for the US and Canada. |

|ecom_billto_postal_postalcode |Yes |20 |Cardholder's billing zip or postal code. |

|ecom_billto_postal_countrycode |Yes |2 |Cardholder's billing country. Use ISO 3166 |

| | | |two letter codes. |

|ecom_billto_telecom_phone_number |No |16 |Cardholders billing phone number. |

|ecom_billto_online_email |Yes |75 |Cardholder's e-mail address, such as |

| | | |John@. |

|ecom_payment_card_name |Yes |50 |Cardholders name as it appears on credit |

| | | |card. |

|ecom_payment_card_number |Yes |19 |Payment card account number. |

|ecom_payment_card_expdate_month |Yes |10 |Payment card expiration month, as represented|

| | | |by a number, such as 1 for January, 2 for |

| | | |February and so on. |

|ecom_payment_card_expdate_year |Yes |10 |Payment card expiration year, as represented |

| | | |by four digits, such as 1999, 2000, 2001, and|

| | | |so on. |

Page 22, #28 Electronic Check – Internet:

“A Payment Gateway will be provided that allows users of State websites to initiate payments by credit cards, debit cards, ACH debit and electronic checks.” After review of section 15, Metavante is the facilitator outside of the BOA sponsored eStores Gateway. The Metavante site promotes EBPP and provides no detailed information regarding e-check service. Current information from EStores web site does not identify e-check acceptance capability in their technology information.

Question: Can BOA identify the Gateway provider, provide development API information, and identify what name/value pairs will support the GL reporting data? (this may be the same question as above)

Need to have further discussion with SOF and BOA technical team to address this question.

Page 24, #32 Daily Settlement & Reconciliation File.

“BOA currently provides the State daily settlement file for credit cards

Question: Yes, but does BOA, processors, network associates, and supported gateways have the ability to retain the credit card transaction detail information? Here is the fundamental problem. Please clarify!

We are currently working on retention standards for transaction and information files. While we will meet regulation for the retention standard, our plan is not to be the data storage facility for this process. We assume data storage requirements are administered within existing general ledger system(s).

Other/Comments:

The FLAIR GL reconciliation by Deposit number is not a Treasurer’s Office requirement, but a state-wide agency financial management requirement. The whole concept of the multi-agency consolidated collaborative effort is to not only get the money in the bank and identify the Agency deposit in FLAIR (Treasurer role), but to automate the identity of the GL revenue amount by deposit # in FLAIR (agency role).

The Agency may also need a subset of the deposit GL information (electronically) to update the agency maintained application (Agency Store front and fulfillment applications).

Some Agencies have adopted the business decision that GL Reporting and application reconciliation is a prerequisite to agency fulfillment (License issuance/renewal).

Bank of America Discovery Questions

July 31, 2001

Bebe Smith, R&D, State Technology Office

850.413-6617

Page 1, #2 Purpose-

“As well, our Bank of America Treasury Management Team is capable of supporting the electronic payment services needs outlined in the RFP.”

Question: BOA Treasury Management Team. Who, where, and what is their experience?

Maureen Gallagher, is the Treasury Management Officer for the State of Florida. She has offices in both Tallahassee and Tampa. Maureen leads the Bank of America Government Treasury Management Team in Florida, and works with a number of government (state and local) clients around the State. Her primary client is the State of Florida. She has been with Bank of America for 12 years and served in operations management, project manager and cash management roles.

Page 1, #3 Purpose –

“ Bank of America will provide alternative service options for the State on a case-by-case basis where needs can not be met by the bank’s proprietary network and services.”

Question: What are these alternate services? Examples? The RFP response by BofA did include proprietary network solutions. If a SOF agency requires an alternative network for services then an alternate agreement will need to be executed. BofA has established relationships with several different networks and will assist to accommodate the needs of those agencies.

Page 2, #5-7

Pg.2 Andrea Morris as primary contact, pg 6 key contact. Pg 7 Brent Chambler as primary contact, pg 2 = key player.

Question: Who interacts with Metavante? Bank of America will partner with Metavante to deliver the solution proposed in our RFP response.

Question: Define Metavante’s role. Bank of America has a partnership arrangement with Metavante, for the development of a CIP (Customer Initiated Payments).

Question: Three people are identified. Which will be the primary contact? Andrea Morris will be the key contact for the State. Maureen Gallagher and Sabrina Dehlinger will work closely with Andrea, through the initial implementation of this service (November 2001).

Page 3-4, #5 Management Plan

Question: Please clarify who performs these roles? 1. Andrea Morris is the primary Sales Representative and contact for the SOF. 2. Eveline Zernetzki is the Account Manager and will assistance in the relationship once the accounts are established. 3. Sabrina Dehlinger is the Regional Sales Manager, secondary contact. 4. Keith Thompson is the Client Manager for SOF.

Page 4, #6 Quality Control

“our systems now automatically upload from one system to the next”

Question: What if down, interruption of service, etc. Where is data held ? If an interruption in service should occur, Bank of America would deliver data to the State at the time our systems are available. Our recovery processes are fully tested and back-up facilities can be implemented quickly should an emergency arise.

Page 8, #12, Customer Service

Question: Please explain CADRE and how it will help the SOF? CADRE is an internal chargeback imaging system that provides the process for BofA to manage our bankcard chargebacks.

“In the event of a chargeback, a debit/credit notice is mailed advising the business of the debit/credit to the business account.”

Question: Please explain this. Notification of chargebacks are done via mail or fax. The individual agencies can specify how and where they want notifications sent.

Page 14, #17 Start-Up and Implementation:

The costs reflect conversion and implementation.

Question: How long and/or is it ongoing for how many agencies? Upon completion and return of the “Information Profiles” by the individual agencies, we will begin our dialogue and implementation process. Based on the needs of the agencies, implementation can be completed from 10 to 30 days. The implementation will be on going until the needs of each agency is meet.

Page 14, #19 Deployment

Question: Is CIP EBPP capable or does it accept transaction from multiple sources? What is CIP?

Question: CIP is a product/service of BOA, Metavante, who? Who is the owner of CIP? Who customizes it and maintains it? Answered above.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download