Network Controls between 3rd Party Vendors and CSI

API Access - Geezeo, Ensenta, iPay

Third party applications such as Geezeo, Personal Financial Management (PFM), Ensenta Mobile Remote Deposit Capture (mRDC), and iPay, integrated bill pay, are controlled by a Single Sign-On from the Digital Banking product. The third party then calls an API opened by CSI Digital Banking to retrieve information for each customer as they log into Digital Banking. The SSO from CSI Digital Banking to these vendors use an x509 certificate to post a predefined SAML formatted message from CSI to a public vendor service via SSL. PartnerID must be valid based off the certificate and SAML organization that was used. A valid User ID must also be provided. An API call from the vendor uses SSL to encrypt data. The vendor sends a request and sends a response, generating a similar signature for the response. Vendors and CSI keep a private key that will be used in a multi-step process to generate and validate signatures sent in both directions. Any signature that does not match will not be processed.

Bill Pay Vendors

CheckFree

FiServ utilizes transport-based security disciplines to protect the production channel between the partner and Fiserv. Confidentiality and integrity are provided by using the standard SSL (Secure Sockets Layer) security framework over the internet, with certificates as the primary authentication technique.

The CheckFree interface utilizes an enrollment step as well as the Single Single Sign-On (SSO). For CheckFree, we have SSL certificates on our SSO server to authenticate, as well as the use of an initialization vector and three production keys that are sent with each message.

Direct iPay

The Single Sign-On process contains two primary steps: the User Authorization Token request and the Subscriber Login attempt. When this request is received, a unique one-time-use Session ID will be created. A response will then be returned that will contain the unique Session ID to use in the subsequent Subscriber login attempt. Once the user is authenticated or after a predetermined amount of time, the Session ID will be marked invalid and can never be used again.

The BillPay application website security uses SSL encryption to ensure all communications between systems are secure. BillPay cryptography will support 3DES encryption algorithms. Initialization Vectors will be passed with encrypted data.

Integrated iPay uses the API process described earlier in this document.

70019