Introduction

The ability for It’s Me 247 Online/Mobile Banking, BizLink 247 Business Banking, or even CU*BASE GOLD to be the central authority for user access to third-party systems is an increasingly popular technique for supporting member interactions in the world of interconnected systems.

CU*Answers is committed to projects that add these integrations for our credit unions’ members. We want to help you. We want to support these relationships. And we value these new connections to strengthen and expand our network for the benefit of members. At the same time, based on our experience and our responsibility to maintain a secure network, a strong tool set, and a sustainable organization for our owners and clients, we must exercise due diligence and appropriate caution when evaluating every new project request.

Purpose

With the number of vendors and SSO designs expanding every day, this Best Practices strategy was developed to allow us to support rapid development while still maintaining our high standards for securing member data and network resources.

It is not intended as a technical document, but rather to describe, in layman’s terms, the business logic behind why CU*Answers might or might not choose to pursue a particular integration project.

General Guidelines

As the name implies, Single Sign On (SSO) integrations allow a member (or CU employee) to authenticate once, and from there click a simple link to access separate websites and tools without the need to remember or type user names and passwords over and over again. The link might be a simple one-time request for some information to be displayed (like a check image), or could initiate a jump to a separate website (like an online PFM tool), or other techniques with varying degrees of complexity.

Buyer beware! If you’re talking to a vendor and they say “we already have an integration with CU*Answers” make sure you understand exactly what that integration really is.  It is very common for us to hook up to only a single product offered by that vendor, or a limited subset of what they sell.  If they’re selling you something more, your project will likely require new development and may not even be able to leverage much of the existing integration. That will affect what you pay and how long your project will take.

For the purposes of this discussion there are three main types:

• Data Retrieval: A basic server-to-server communication mechanism to retrieve data on behalf of the member and pull it back to the authenticated system. Example: cleared check images.
• SSO Handoff to Another Website: A more complicated process than data retrieval, the SSO handoff to a 3rd party website can involve multiple server-to-server communication steps to establish authentication before the final redirect of the member to another website. Example: online bill payment.
• Integration: A customized, full-featured integration with a vendor that includes data exchange even beyond that which is needed for the SSO. As many variations as there are vendors, with expanded rules of engagement and end-user access techniques. Example: eDOC Innovations Photo ID vault, which includes an SSO to scan and store IDs as well as SSO links to retrieve stored images.

Many of the interfaces we’ve developed over the years are hybrids of more than one of these types, and the specific techniques to accomplish them have almost as many variations as there are vendors and CUs who need them.

Sample Online Banking Integration Techniques

The following table groups similar types of online banking interfaces. This list is not exhaustive, nor intended to limit the types of integrations we will do, but rather is presented to describe how our experience will be applied to requests for new projects, and adapted to new technologies as they come along.

*OTB = Off Trial Balance, our term for member savings and loan products that are not retained on the CU*BASE member database but rather exchanged via a third party. CU*BASE maintains a basic database record, typically updated via independent data exchange with the vendor (separate from the SSO), to document the presence of the account for CU staff and members online.

Rules of Engagement

General Requirements to Move Your Project Along

As stated above, this document is not intended to provide technical specifications for integrations, but the rules and checklists below are an important first hurdle to cross in moving your project forward with our development teams.

As our discussions about your project progress, more detailed technical specifications will be provided, and those, along with the business rules defined here, will become the standards against which the final integration specifications will be measured.

Remember that although our teams will be as flexible and innovative as possible, they will not compromise when it comes to basic requirements to protect your member data and the integrity of our network, your credit union included. Credit unions or vendors that wish to circumvent any of our guidelines, outlined here or published elsewhere, will be requested to agree to formal indemnification agreements, to be determined upon advice of legal counsel.

Analyses to be Completed

The decision-making process involves several separate evaluations that will be completed by various experts here at CU*Answers, based on consultations with and information received from both your credit union and your chosen vendor. (See also “Decision Checklist for New Projects” below.)

1.     Business Analysis 
As described throughout this document, our team looks at each integration project from a big-picture standpoint to evaluate how it fits with current and future corporate goals and direction. We consider whether the CUSO will be investing its own funds to produce an end-product that will ultimately become a standard product offering to all network participants, or if it’s just a simple custom connection to facilitate your credit union’s desire to do business with a certain vendor. We also consider whether a similar vendor’s product is already in development.  This analysis will not only determine whether we move forward and how, but also whether CU*Answers will help fund the project.

2.     Risk Assessment
Our compliance and security experts will perform a risk assessment that will evaluate, from our perspective, any potential risks to your credit union, as well as to the CUSO and other network participants.

3.     Data Security Evaluation
Among other things, projects will be considered according to the vendor’s ability to adhere to standards like these:

• Data Retrieval SSO: Server-to-server request establishes authentication and authorization, member data and response is sent over the wire fully encrypted. HTTPS and IPSec is used to secure transmission of data.
• 3rd Party Website SSO: Server-to-server request establishes authentication and authorization, returning a session token and URL to the client server. HTTPS and IPSec is used to secure transmission of data. Session token is used to direct the member to the requested web resource. Flexible XML delivery of required member data is established per vendor.

NOTE: CU*Answers does not maintain OFX servers.

4.     Code Review 
This evaluation includes a more detailed analysis of the workflow, user interface, database structure, and other elements to look for overall compatibility with our current infrastructure. In a nutshell, this evaluation is to determine whether the project is even possible within our existing hardware and software framework.

Decision Checklist for New Projects

Following are factors that will be needed for evaluation of your project:

• What will the end-user interface look like? Where does the jump happen (in other words, what do members/staff see and what do they click on)?
• Will enrollments or other status information need to be kept synchronized between the vendor and CU*BASE? Does the system need to evaluate member eligibility even to sign up to use the service? (Such as if you wanted to offer an SSO only for your business accounts or members with certain types of checking accounts.) What database infrastructure and end-user tools will need to be added to CU*BASE to support this synchronization or rule set? This will affect implementation windows based on the need to coordinate with CU*BASE software release schedules.
• Will activation be controlled by a CU*BASE database element? (This is our preference is most cases, at least to facilitate our analysis of credit union participation.) Will statistical data be needed to allow for CU*BASE dashboards or other end-user tools for CU employees?
  

  For example, when we developed our initial bill pay interfaces, tools were created in parallel for both CU*BASE and It’s Me 247. Enrollment could be done by a CU employee in CU*BASE or online by the member. Bill pay activity stats were retained for use by various CU*BASE dashboard analysis tools. On the other end of the spectrum, MoneyMap is activated by a simple on/off flag but no enrollment or other status details are maintained on CU*BASE. An interface like the former significantly increases the project timeline to allow for CU*BASE development program efforts, in addition to the SSO work itself.

• Does there need to be a member fee posting structure in place for members who use the service? Will it need to include relationship waivers (like age/aggregate balance, or even Tiered Service/Marketing Club waivers)?
• Will there be a need to add language to the End-user License Agreement (EULA) that members sign when logging in for the first time, or a new standalone EULA to be stored in CU*BASE and presented when the user enrolls in the service?
• How much of the data needs to be encrypted? This is an critical, required security measure but does place greater strain on resources as encryption is CPU intensive. An evaluation will need to be done as to whether it will be necessary to encrypt all data elements, or just specific fields such as account base, Social Security number, etc. Likewise, to ensure that the data being shared is reasonable and does not exceed the bounds of the specific project requirements, the vendor will need to provide a comprehensive list of all data elements to be exchanged for review by our development and internal auditing teams.
• Do we need to enforce a key cycle process with the vendor (for regular exchange and rotation of encryption keys)? Requires significant overhead to develop and manage; currently done only for the Fiserv bill pay integration.
• What activity logging and exception handling processes will be needed?
• We’ll also want to get a general sense of the nature of your relationship with this vendor: how long they’ve been in business, long-term prospects for ongoing development and evolution of the interface, etc. Although no one can predict the future, for everyone’s sake we want to do everything we can to avoid getting into a vendor relationship that goes sour.

Do Your Own Due Diligence

When CU*Answers does a project with a third-party vendor, we do perform our own assessment. However, our due diligence is not the same as that which your credit union is obligated to perform. Even if you’re choosing someone with whom we’ve already established an interface that’s being used by other credit unions, your credit union is still responsible for performing your own risk assessment and due diligence on that vendor.

If you’re recommending a vendor that’s brand-new to the network, it’s especially important that you are confident the vendor has good security practices, financial stable, and has some experience in completing the type of interface you are looking for, especially when it comes to connecting to a multi-tenant (data center) environment like ours.

Tips for what your review should include:

• Control audit
• Financial statement
• Insurance coverage
• DR/BR policy and most recent tests
• Information security policies and assessments
• The data being exchanged and risks associated with releasing this information to the vendor

Related Materials

Following are related Best Practices that should also be reviewed in conjunction with your SSO project request.  All are available via CU*Answers Best Practices.

• Secure Document Exchange with It’s Me 247
• Secure Data Exchange with CU*Answers’ CU*CheckViewer
• Integrating Third Party Applications with CU*BASE GOLD
• Online Banking Check Images Project Management Site

Project Steps

Procedures

To initiate a formal request, use the procedures outlined in the separate “Initiating a Special Project Request” document, or simply contact any Client Service Representative to get the ball rolling.

Typical Development Timelines

Every integration project is unique. The exact development timeline will depend heavily on specific project requirements, similarities to existing interfaces, vendor responsiveness, and many other factors. Something as simple as activating an existing data retrieval interface might require only a few weeks, while a full-blown integration with data synchronization or exchange elements might require a minimum of six months or more to complete, plus time for beta testing, documentation, and other implementation rollout tasks. Therefore, as described previously, a timeline will be estimated for you after the initial evaluations have been completed.