99
Yodlee Confidential i Yodlee ® SDK Developer’s Guide Version 12.0

Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

  • Upload
    others

  • View
    29

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Yodlee® SDK Developer’s Guide

Version 12.0

Yodlee Confidential

i

Page 2: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Copyright (c) 2013 Yodlee , Inc. All rights reserved. Technology protected by one or more U.S. Patents or Patents Pending. Use subject to license terms. May include materials developed by third parties. Yodlee and the Yodlee Logo are trademarks or registered trademarks of Yodlee, Inc. in the U.S. and other countries. All other trademarks mentioned in this document or Website are the property of their respective owners.

Yodlee Confidential

ii

Page 3: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Contents

1 About This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

1.1 What This Document Discusses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11.2 Who Should Read This Document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11.3 Other Documents of Interest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11.4 After Reading This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

2.1 What’s New in 12.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12.2 Features Introduced in Prior Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

2.2.1 Version 11.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22.2.2 Version 10x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

2.3 Recommended Developer Skill-Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32.3.1 SOAP Developer Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

3 Platform Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13.2 Platform Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13.3 Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

3.3.1 Other Processes and Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3

4 Implementation Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

4.1 Deployment Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14.1.1 SOAP Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14.1.2 Hybrid Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

4.2 Deployment Mode Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24.3 Client-side Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34.4 Server-side Environment Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

4.4.1 Edit Credential API Enable/Disable . . . . . . . . . . . . . . . . . . . . . . . . . . 4-44.5 Development Environment SLA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-44.6 Production Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-54.7 API SLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5

Yodlee Confidential

iii iii

Page 4: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

4.7.1 API Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-54.7.2 API Backward Compatibility Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6

5 API Packaging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

5.1 SOAP Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15.1.1 Core Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15.1.2 Extension Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-35.1.3 Common Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-35.1.4 Services Overview Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4

5.2 REST Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-55.2.1 REST Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-55.2.2 Yodlee RESTful Services and OAuth . . . . . . . . . . . . . . . . . . . . . . . . 5-6

6 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

6.1 Cobrand Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16.1.1 Usage of the CobrandContext in the SDK. . . . . . . . . . . . . . . . . . . . . 6-1

6.2 User Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26.2.2 User Authentication Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-36.2.3 Including Client IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4

6.2.3.1 Use Case Excerpt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-46.2.3.2 How to Set the IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4

6.3 Default Timeout Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5

7 Data Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

7.1 Users and Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17.2 Data Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17.3 Data Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-27.4 Data Service Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

7.4.1 Split Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-37.4.2 Data Extents and Summary Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-37.4.3 Data Service Lite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-57.4.4 Content Service Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-57.4.5 Transaction Search Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5

Yodlee Confidential

iv

Page 5: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

7.5 dataservice.type to ContainerName Mapping . . . . . . . . . . . . . . . . . . . . . . 7-67.6 Entity Relationship Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-77.7 Dataservice.type Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8

7.7.1 BankData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-87.7.2 BillPayServiceData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-87.7.3 BillsData. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-97.7.4 CardData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-97.7.5 DealData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-107.7.6 HotelReservationsData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-107.7.7 InvestmentData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-107.7.8 InsuranceLoginAccountData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-117.7.9 LoanLoginAccountData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-137.7.10 OrdersData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-147.7.11 RewardsPgm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-147.7.12 Real Estate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-147.7.13 TaxData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15

7.8 Class Hierarchy for MFA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-157.8.1 MFA Refresh Info. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-157.8.2 MFA User Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-167.8.3 MFA Question Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16

8 Implementation of SDK Functions. . . . . . . . . . . . . . . . . . . 8-1

8.1 Gzip Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-18.2 Web Services Security (WS-Security) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-18.3 Account Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8

8.3.1 Adding a Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-88.3.1.1 MFA Content Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9

8.3.2 Editing Account Credentials. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-98.3.3 Form Data Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9

8.3.3.1 FieldType. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-118.3.3.2 FieldInfoSingle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-118.3.3.3 FieldInfoMultiFixed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-148.3.3.4 FieldInfoChoice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-188.3.3.5 Sub-Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-198.3.3.6 FieldInfoMultiVariable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-20

8.3.4 Helping the User Enter Correct Values . . . . . . . . . . . . . . . . . . . . . . 8-208.3.4.1 Help Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-208.3.4.2 Validation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-218.3.4.3 User Profile Mapping Expressions . . . . . . . . . . . . . . . . . . . . . 8-21

Yodlee Confidential

v v

Page 6: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

8.3.5 Retry Form After a User Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-218.3.5.1 FieldInfo Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-228.3.5.2 AutoReg Field Level Error Messages . . . . . . . . . . . . . . . . . . . 8-22

8.4 Account Management for MFA Items. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-228.4.1 MfaQuestionAnswer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-22

8.5 MFA Refresh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-238.5.1 MFARefreshInfo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-238.5.2 MFAFieldInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-23

8.5.2.1 ImageFieldInfo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-238.5.2.2 TokenIdFieldInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-248.5.2.3 SecurityQuestionFieldInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-24

8.5.3 QuestionAndAnswerValues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-258.5.3.1 SingleQuesSingleAnswerValues. . . . . . . . . . . . . . . . . . . . . . . 8-278.5.3.2 SingleQuesMultiAnswerOptionsValues. . . . . . . . . . . . . . . . . . 8-278.5.3.3 MultiQuesOptionsSingleAnswerValues. . . . . . . . . . . . . . . . . . 8-278.5.3.4 MultiQuesMultiAnswerOptionsValues . . . . . . . . . . . . . . . . . . . 8-27

8.5.4 MFAUserResponse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-288.5.5 MFATokenResponse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-288.5.6 MFAQuesAnsResponse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-288.5.7 MFAImageResponse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-298.5.8 QuesAndAnswerDetails. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-298.5.9 Retrieve MFA Question Answers. . . . . . . . . . . . . . . . . . . . . . . . . . . 8-298.5.10 MfaQuestionAnswer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-298.5.11 Update MFA Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30

8.6 Historical Account Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-308.6.1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-308.6.2 Operation and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-308.6.3 History Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-318.6.4 Dataset Interpolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-318.6.5 Account Data Included. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-318.6.6 Custom Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32

8.7 MFA Refresh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-328.7.1 Get MFA Information for User Display . . . . . . . . . . . . . . . . . . . . . . . 8-328.7.2 Send User Provided MFA Information . . . . . . . . . . . . . . . . . . . . . . . 8-328.7.3 MFA Refresh Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-34

8.8 Yodlee Hosted Wizards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-358.8.1 Yodlee Hosted Wizard Example: Yodlee FastLink. . . . . . . . . . . . . . 8-36

Yodlee Confidential

vi

Page 7: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

9 Upgrade Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

9.1 Support for WSDL in Version 12.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

10 Common Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

10.1 Invalid Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-110.2 Logging SOAP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2

11 Reporting Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

11.1 How To Report Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-1

A Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1A.2 Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

Yodlee Confidential

vii vii

Page 8: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Chapter 1: About This Document

1.1 What This Document Discusses

The Yodlee® SDK Developer’s Guide provides software developers and business managers with a general understanding of the features, capabilities, and implementation options available with the Yodlee Software Development Kit (SDK). Based on this:

It is possible to design and construct applications that leverage data aggregation technology in the areas of personal financial management (PFM), wealth management (WM), electronic bill presentment and payment (EBPP), risk management (RM), and data products (DPs).

Specifically helps software developers and business managers associated with financial institutions to implement the Yodlee Software Development Kit (SDK).

1.2 Who Should Read This Document

1.3 Other Documents of Interest

In addition to this guide, other key resources that may prove useful when building SDK-based solutions include:

Audience Description Of Interest?

Sponsor The sponsor is the person who controls the purse strings and gives final approval to purchase the Yodlee product. The executive may also be the person who will manage the product at a high-level.

Not really. The doc is technical and provides a general understanding of the Yodlee SDK and how to design and construct applications on top of the SDK .

Product Functional Lead

The product manager is the person in closest contact with the Yodlee account manager (TAM). This person is typically responsible for approving the features/functions delivered to your consumers.

Yes to some extent. The doc explains the general understanding of the application features,capabilities and implementation options available with the Yodlee SDK.

Technical Lead

The technical lead is the person who will implement the Yodlee application and is the primary point of contact with the Yodlee technical team. The technical lead will be involved in the behind-the-scenes integration work between the customer and Yodlee.

Yes. It presents must know technical information about general understanding, features, capabilities, and implementation options available with the Yodlee Software Development Kit (SDK), and an understanding of how to design and construct applications that leverage data aggregation technology and sit on top of the SDK

Support Support people keep consumers happy and work most closely with Yodlee’s customer care team to resolve issues and file bugs on their behalf

Yes. The support team at the financial institution who work with customer service will get a sense for the features of the Yodlee Software Development Kit(SDK).

Chapter 1: About This Document

Yodlee, Inc. © Copyright 2013 Confidential

1-1

Page 9: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

After Reading This Document

1-2

WSDL Documents and Javadocs - These documents provide a detailed description of all API calls supported by current Yodlee version. They are used primarily by developers when they are architecting applications and writing code.

Yodlee FinApp Developers Guide - This document provides information on the FinApp developer platform provided by Yodlee. The FinApp developer platform enables individuals/business entities to build their own financial applications and showcase them to consumers through the Yodlee FinApp Center.

Yodlee PersonalFinance SDK Implementation Guide – The Yodlee SDK Implementation Guide provide information about various APIs that are used to write applications or features using appropriate SDK.

Yodlee PersonalFinance FinApp REST API Guide - This document explains the various REST APIs currently used by the FinApp platform.

Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with Yodlee applications.

Yodlee EasySignOn Overview - This document provides an alternate approach to financial institutions who are interested in implementing a simpler version of single sign on (SSO).

1.4 After Reading This Document

Yodlee® welcomes your comments and suggestions on the quality and usefulness of this document. Please feel free to share your input with the documentation team by sending an email to [email protected]

Chapter 1: About This Document

Yodlee, Inc. © Copyright 2013 Confidential

Page 10: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Chapter 2: Introduction

The Yodlee SDK Developer’s Guide outlines core concepts and capabilities of the Yodlee version 12.0 SDK, as well as provides implementation details for many common activities.

From 9.0.3 onward, the Yodlee SDK has been enhanced to support the use of WSDL files using the doc-literal encoding standard. Customers are not required to download client libraries, unlike earlier. SDK customers can now download the WSDL files to their development environment and generate the client-side SOAP stubs in the framework of their choice. In addition, the XML response from the SDK server has been optimized for performance and supports the gzip encoding compression mechanism.

It is suggested that business managers familiarize themselves with this document. Developers should go further by reviewing the supplied source code, Java docs, and running the sample applications in preparation for developing their solutions.

2.1 What’s New in 12.0

The following features have been added to the Yodlee SDK platform and are detailed below:

Site account addition – The Yodlee SDK has been enhanced to add site accounts. Site accounts is a feature in which different types of accounts available under a single site are added when the consumer selects a site and provides the credentials. Pre 12.x versions do not have the capability of adding different types of accounts belonging to a site by a single action. For example, consumers have to explicitly add banking and credit card accounts available in the same site although the site and the credentials used to access these accounts are the same. In 12.0 all accounts under a single site are added.

Enhanced site search – Yodlee has enhanced the site search capability to make it more intuitive. Yodlee now maintains a list of popular site based on consumers' site addition traffic. This network is in addition to the current pre-configured list of sites that a customer can provide at the time of cobranding. The list of sites returned for a given search string is now based on the pre-configured list and the dynamic network. The matching sites functionality that is already available in prior versions has been enhanced. Consumers can provide substrings, aka (also known as), or keywords to search a site and the site search results are returned in the decreasing order of their popularity. Common sites are the ones that match the search criteria and are most commonly searched. This list contains the most popular of the sites returned by site matching. The matching results section lists all sites that match the search string.

Suggested sites – The Yodlee SDK has been enhanced to present a list of sites that a consumer might want to add. The SDK will now return a list of popular sites based on consumers' site addition traffic rather than a pre-configured list.

REST APIs - Yodlee SDK offers access to Yodlee data in the form of RESTful services. These services are lightweight APIs that provide faster access to consumer's data like accounts, transactions, spending and budgets. SOAP APIs are used to access more detailed information.

Chapter 2: Introduction

Yodlee, Inc. © Copyright 2013 Confidential

2-1

Page 11: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Features Introduced in Prior Versions

2-2

2.2 Features Introduced in Prior Versions

2.2.1 Version 11.0

Financial institution metadata localization – The Yodlee SDK has been enhanced to support the return of localized metadata for financial institutions. For example, a consumer accessing a French language site sees the site names in French and provides the credentials (user name, Q&A) in French.

Hosted wizards – Commonly used functions such as link account and add payee are available on the Yodlee platform as hosted wizards. Hosted wizards are flows with a fixed start and end that Yodlee has built for best user experience and performance. SDK customers can reuse these flows and avoid spending additional time rebuilding the features. Hosted wizards include:

Yodlee FastLink

Edit account wizard

Registration wizard

Add payee wizard

Add payment account wizard

Shared site engine – The Yodlee SDK has been enhanced to automatically check if a consumer has additional products at an institution and add those products during a nightly refresh. For example, a consumer may add Bank of America - Checking and Savings and during the nightly refresh Yodlee SDK detects a mortgage account. Yodlee SDK will automatically include this additional account that the consumer has not yet added, by adding a new item for Bank of America - Mortgage.

Summary information on a consumer's activities – The Yodlee SDK includes a new API that will return summary information on the activities performed by the consumer. Activities include:

Adding banking/credit card/ investment accounts

Creating a budget

Selecting alert options

This API will help SDK customers build their own getting started functionality within their application.

NOTE: These enhancements are only available to SDK customers and are not available to customers of the SDK Entrepreneur Edition.

2.2.2 Version 10x

CompareMe – The Yodlee platform has been enhanced to store summarized data points by category at various levels including users and across financial institutions.These data points are stored for different periods of time like for a week, month or year and can further be classified and stored by ZIP code, city and state.

Chapter 2: Introduction

Yodlee, Inc. © Copyright 2013 Confidential

Page 12: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Recommended Developer Skill-Set

The SDK has been enhanced to provide a new API through which this data can be accessed. Again this data can be used to provide an insight to consumers on their spending patterns and compare them with other users who belong to the same ZIP code, city or state. For further details on how to use the Compare ME SDK, please refer to the Yodlee PersonalFinance SDK Implementation Guide.

NOTE: The CompareMe feature is only available to SDK customers, and is not available to SDK EE customers.

Retrieving 1099 Tax Documents – The Yodlee platform has been enhanced to aggregate 1099 tax documents, and this data can now be retrieved through the Data Services API in the SDK.

Important! This feature is available only if Yodlee TaxCenter is enabled and applicable for financial institutions that use hosted applications along with APIs.

Using Simple Description – Yodlee has introduced the Simple Description feature to show a simplified description to the consumer to help comprehend where and what the transaction is all about. Yodlee recommends that SDK developers use this type of description in place of the original description / custom description being used earlier to display appropriate transaction information to the consumer.

NOTE: Simple Description is an additional field in Transaction Search response, where original and custom descriptions continue to remain available.

2.3 Recommended Developer Skill-Set

Yodlee recommends the following minimum skill set and experience for Yodlee SDK developers. Skill sets vary slightly depending on whether the application will be deployed in SOAP mode.

2.3.1 SOAP Developer Requirements

Four or more years of experience in the following:

Ability to translate a customer problem definition into discrete object-based interface definitions.

Hands-on experience implementing error handling and debugging a network application

Three or more years of experience in the following:

Implementation experience with network applications that use and parse XML

Ability to work with a QA group to test, debug, and deploy applications in development and production-class environments

Two or more years of experience in the following:

2-3Chapter 2: Introduction

Yodlee, Inc. © Copyright 2013 Confidential

Page 13: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Recommended Developer Skill-Set

2-4

Implementing a provided API exposed as Web services, which includes:

Understanding WSDL, Javadocs

Setting up and debugging a Web service client/server implementation

Programming in the language of choice (Java, C#, etc.)

Experience using SOAP-based frameworks over a WAN

Understanding security, including handling of server certificates

Design and development capability of medium-scale infrastructure with application servers (as appropriate to the chosen programming paradigm)

Designing and working with data models, specifically matching one data model/hierarchy to another; familiarity with UML is a huge plus.

Chapter 2: Introduction

Yodlee, Inc. © Copyright 2013 Confidential

Page 14: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Chapter 3: Platform Overview

3.1 Overview

The Yodlee SDK exposes all the core data and services provided by the aggregation platform. In fact, all Web applications built and operated by Yodlee in its ASP business are constructed using only the published and documented APIs outlined in this guide. Yodlee SDK customers can use a similar approach to construct their own applications or use them as the basis for entirely new solutions that meet specific, custom requirements. These applications can be designed and constructed for deployment in the customer's environment where the application uses a SOAP-based, Web services approach to access the core data and services exposed by a Yodlee application server hosted in its ASP environment.

3.2 Platform Architecture

While a detailed understanding of the platform architecture is not required to successfully design and develop custom applications, a basic introduction to the core components and processes can prove useful in understanding how the overall system operates.

The Yodlee platform is built on the J2EE 1.6 standard using industry accepted design principles. The APIs provide access to account data, user preferences, account permission, historical data, data refresh services, credit card one-time payments, credit card recurring payments, auto registration, and alerts among other elements. The architecture encourages a clear separation of applications from the core layer and all interfaces exposed are relatively generic and designed such that changes made in the underlying implementation can be done without affecting the external interface. This approach greatly eases the process of upgrading Yodlee applications to future platform releases since new features and application improvements can be made such that existing, published API signatures are not affected - explicitly addressing backward compatibility concerns.

The heart of the Yodlee system is the Yodlee Data Engine and the Yodlee Payments Engine. The Yodlee Data Engine is made up of a set of infrastructure components that intelligently aggregate, cleanse, augment, and store data on behalf of users (after first obtaining and the user's permission and account credentials). The Yodlee Data Engine is capable of aggregating a highly extensible range of data from a large number of data providers using a variety of structured and semi-structured data formats including HTML, OFX, XML, and custom feeds. The data is either collected on-demand or updated "off-line" on a scheduled basis using an intelligent, rules-based system called automatic intelligent refresh (AIR).

Applications accessing data can either retrieve the most recently cached data from the OLTP or request data to be updated from the source on demand. The process of updating data is referred to as a gathering request since it ultimately results in the components known gatherers making a request to the appropriate data source and retrieving the latest information. Refresh requests originating from the application are referred to as instant refreshes while requests originating from the offline cache server are known as cache

Chapter 3: Platform Overview

Yodlee, Inc. © Copyright 2013 Confidential

3-1

Page 15: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Data Flow

3-2

refreshes. Regardless of refresh type, the OLTP DB is always updated with the most recent data collected.

3.3 Data Flow

To fully illustrate the relationship between the various platform components and how the process of updating data works, the following interaction flow description and accompanying diagram are provided. This illustrates how an instant refresh request is handled.

1. The SDK runs in an application server and interacts with the OLTP using the SDK for all data retrieval and update functionality.

2. If the application simply requests the most recently updated data in the OLTP, the data is returned without initiating a refresh request.

3. If the application requests that the data in the OLTP be refreshed, the instant refresh request is placed into a JMS queue that runs on an IBM MQ Series server. (The instant refresh request returns after the requests are generated. Follow-up APIs are provided so that a client can poll to determine the status of the generated request and retrieve the data.)

4. Gatherers pick up these requests in the queues and gather account (Member Item) information from data sources. A data agent specific to each source site handles actual data collection.

5. Responses are placed in a response queue by the gatherers after the collation of the gathered data from the destination data sources.

6. The data in the OLTP is updated by the CAN Server (DB Filer) and made available to the requesting application.

Chapter 3: Platform Overview

Yodlee, Inc. © Copyright 2013 Confidential

Page 16: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Data Flow

3.3.1 Other Processes and Details

Offline scheduled maintenance and other activities are implemented through YTask services. This includes such things as account history generation, creation of bills for custom accounts, and other functions that can be performed in an asynchronous fashion.

The refresh server enables systematic batch collection of data and, using AIR logic, offers configurable means to control the cache run timing, frequency, and other parameters.

3-3Chapter 3: Platform Overview

Yodlee, Inc. © Copyright 2013 Confidential

Page 17: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Data Flow

3-4

The core platform APIs are stateless, allowing for ease in clustering and load-balancing, since there is no requirement of server affinity when designing the system.

The transaction categorization engine enables categorization of user transactions obtained from users' data aggregated from destination data sources. The transaction categorization engine applies a series of algorithms to associate a transaction with the best transaction category.

Chapter 3: Platform Overview

Yodlee, Inc. © Copyright 2013 Confidential

Page 18: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Chapter 4: Implementation Overview

This chapter discusses the implementation alternatives available as well as considerations that must be made with each approach.

4.1 Deployment Options

There are two general deployment options supported:

SOAP

Hybrid Deployments

4.1.1 SOAP Mode

The most common SDK deployment model is SOAP mode, where the platform is hosted by Yodlee as an ASP service and all SDK invocations are made via a web services interface.

The following diagram depicts how an implementation of the Yodlee SDK in SOAP mode fits into the customer's environment. In this scenario, the customer's application integrates with the Yodlee SDK as a local resource. The SOAP client makes the necessary calls to the Yodlee server to get the required information. Secure transport via SSL is used for communication between the SOAP client and the Yodlee server.

Chapter 4: Implementation Overview

Yodlee, Inc. © Copyright 2013 Confidential

4-1

Page 19: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Deployment Mode Considerations

4-2

4.1.2 Hybrid Deployments

The Yodlee platform supports deployments that consist of both SDK and Yodlee hosted applications. Both types of applications can access the same aggregated user data and users become members of all applications - allowing them to maintain the same user name, preferences, and account information across all applications.

NOTE: Hybrid deployments require single sign on (SSO) capability and must support SAML-based user authentication. For more details refer, Yodlee EasySignOn Overview and Yodlee SAML Implementation documents.

4.2 Deployment Mode Considerations

The method of application deployment will have a significant impact on how an application is architected and designed.

The SOAP mode of deployment entails a client application making remote calls (typically across the WAN) to a Yodlee SOAP server. The advantage of deploying in this mode is the clear separation of the Yodlee platform from the customer application(s). The separation allows for distribution of processing resources between the Yodlee server and the application, and allows the Yodlee server to be completely insulated from errant or impolite applications. As discussed previously, this comes with a cost in performance, as the separation enforces that arguments and return values be marshaled and un-marshaled during the communication between the remote client and the server. Typically, with deployments in the SOAP server mode, the granularity of communication with the Yodlee server needs to be carefully considered so that performance and response of the system is within design requirements.

Chapter 4: Implementation Overview

Yodlee, Inc. © Copyright 2013 Confidential

Page 20: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Client-side Certification

A SOAP-based application developer limits the number and type of calls made as well as gives careful consideration to how data is cached on the client side. Additionally, the actual design and workflow of the application UI can often be optimized to reduce the impact of these limitations on the overall user experience. Business owners responsible for the application experience should keep this in mind when defining SOAP-based applications and feel free to consult with Yodlee for guidance, if needed.

Yodlee has support for a SOAP doc-literal scheme for defining the SOAP service interfaces and the underlying communication. In the doc-literal scheme, the service interface is usually flat – typically a single service interface call where a document instance is passed in the request to the remote server and a document instance is received in response. What is in the document (both request and response) is defined using an XSD and the meaning of the elements in the document is outside the confines of the SOAP protocol and its handling. This style of communication is optimized for direct XML document handling at both ends (client communication as well as server processing). Libraries like JAXB are available to transform the XML to objects in the Java language and vice-versa to write out documents from object instances.

While the SOAP communication itself occurs in XML, the structure of this XML is itself optimized to enable binding at both ends to a SOAP processor that transforms it to an object.

The WSDL files can be downloaded from the SDK server URL provided by the Professional Services team. Customers can then generate their own client side libraries in the framework of their choice.

For example, if the customer is using axis-1.4, it needs to use this framework to generate the client-side libraries.

NOTE: Yodlee platform is compliant with the following:

SOAP 1.1

WS-I Basic Profile 1.1

4.3 Client-side Certification

Yodlee SOAP server has been certified against, the following client side technologies:

Axis2 v 1.4.1

.NET v 2.2.30729

Axis 1 v 1.4

4.4 Server-side Environment Configuration

There are some configuration settings possible on the Yodlee server that Yodlee can set. During implementation this would be done by the Yodlee Professional Services team and after launch would be managed through a Yodlee CustomerCare service request.

4-3Chapter 4: Implementation Overview

Yodlee, Inc. © Copyright 2013 Confidential

Page 21: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Development Environment SLA

4-4

4.4.1 Edit Credential API Enable/Disable

After a user has added an item in the Yodlee system it is possible for the SDK to retrieve what that credential is. This is useful for supporting show password functionality to the user. Yodlee is able to disable this API, essentially making the credentials write-only.

Yodlee does this by updating the server side API restrictions (com.yodlee.core.api.disabled) to include (VIEW_CREDENTIALS).

NOTE: This feature is not available for SDK EE (Enterprise Edition) customers.

4.5 Development Environment SLA

During the development, QA, and testing phase of application development, ASP customers should use a Yodlee development environment (YDE) hosted by Yodlee, in a stage environment. This is a functional system with the latest version of the Yodlee platform installed.

Specifically, the environment includes:

Access to the most recent version of the Yodlee platform

A SOAP 1.1 compatible server The ability to support on-demand refreshes of aggregated data from live data sources

Access to test accounts that simulate user accounts (obviates the need to use "live" user accounts during application development)

Access to an instance of the Yodlee MoneyCenter application (useful for creating users, adding accounts, testing functionality of system, etc.)

A cobrand (namespace) and application ID

The YDE should be used for development and functional testing of applications throughout development only. Additional restrictions for use of the YDE include:

The number of users created in the YDE is restricted to the minimum required to perform development activities (maximum not to exceed 50)

No load testing or other stress testing of the application should be performed in the YDE

Applications accessing the YDE cannot be used for any commercial purposes. Commercial or production releases of applications must use a licensed, production environment.

Yodlee makes best efforts to ensure 100 percent uptime of the YDE but reserves the right to take the YDE down for regular maintenance and upgrades without prior notice. Generally, maintenance windows are scheduled during off hours and weekends to minimize disruption, and upgrade notifications broadcast to the users in advance.

Yodlee does not move money in the YDE, so products that require money movement such as Yodlee BillPay, Yodlee FundsTransfer, Yodlee

Chapter 4: Implementation Overview

Yodlee, Inc. © Copyright 2013 Confidential

Page 22: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Production Environment

ChallengeDepositVerification, etc. will not be able to be production tested before a pilot.

To establish a YDE for a project, please contact a Yodlee Sales Representative or Project Manager.

4.6 Production Environment

After development and initial testing is complete, a production environment is provisioned (provided a production license of the SDK has been purchased) and the customer's application is redirected to point to this new environment. At this stage, final QA, and user acceptance testing is typically performed before going live. Service level agreements (SLAs) governing operation of this environment should be specified as part of the customer’s production SDK license.

4.7 API SLA

Yodlee has established the following policies to regulate support for the various APIs published in the Software Development Kit.

4.7.1 API Lifecycle

APIs, like any other product or service, are subject to a standard lifecycle described below. All APIs in the Yodlee version 10x series platform follow each phase sequentially and cannot reverse from one phase to a previous one.

Beta - an API is published but is not guaranteed to function or include complete documentation. The signature of a beta API may also change before it is promoted to the next phase. All beta APIs are listed in either the release notes or Javadocs for a particular release.

Supported - an API is guaranteed to work as documented and its signature is guaranteed not to change. In general, customers should only be using supported APIs. Unless otherwise noted in the release notes or Javadocs, an API can be assumed to be supported.

Deprecated - an API is guaranteed to work as documented and its signature is guaranteed not to change. Typically, the functionality of a deprecated API has been replaced with a newer, supported API, which should be the one used. All deprecated APIs are listed in either the release notes or Javadocs for a particular release.

Obsolete - an API is not guaranteed to work. No applications should rely on obsolete APIs. If published, all obsolete APIs are so noted in either the release notes or Javadocs. In general, obsolete APIs are deleted rather than published.

In addition to the phases described above, the following policies are also enforced.

4-5Chapter 4: Implementation Overview

Yodlee, Inc. © Copyright 2013 Confidential

Page 23: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

API SLA

4-6

No API shall transition from supported to obsolete in less than 24 months. This period shall be measured from the date of the release an API first becomes supported until the date of the release in which it first becomes obsolete.

24 months or 2 releases prior

No API shall skip the deprecated phase. The deprecated phase must last a minimum of one minor release cycle or 9 months, whichever is longer.

APIs may skip directly from the beta to obsolete phase (i.e., beta APIs never need become supported).

These restrictions only apply to APIs published within a given major release (signified by the digit to the left of the first decimal point).

4.7.2 API Backward Compatibility Policy

Notwithstanding the API lifecycle outlined above, Yodlee guarantees that the signature of APIs in the supported or deprecated phase will not change in subsequent minor and patch releases. Yodlee reserves the right to break compatibility of APIs between major releases.

Chapter 4: Implementation Overview

Yodlee, Inc. © Copyright 2013 Confidential

Page 24: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Chapter 5: API Packaging

5.1 SOAP Development

This section provides an overview of how the SOAP APIs are packaged in the Yodlee platform.

Core services are organized into different WSDL files that provide a logical and intuitive separation of the services by the kind of functionality they fulfill. These service WSDL files map one-to-one with the Java interfaces of the server APIs that the SOAP layer is built on top of.

Javadocs are provided as a companion reference along with the WSDL files and provide detailed information on the capability of each of the service interfaces, the arguments expected in each method invocation, and the exceptions that can be raised by the method. These Javadocs supplement the reference information provided in the Yodlee SDK developer documentation and serve as a valuable resource for developers to understand the Yodlee APIs and their capabilities.

SOAP API packaging corresponds to the following packaging in Javadocs.

Core services corresponds to com.yodlee.soap.core in the Javadocs

Extension Services corresponds to com.yodlee.soap.ext in the Javadocs

NOTE: Javadocs also describe common objects that constitute argument types and return values for the SOAP APIs (corresponds to com.yodlee.soap.common in the Javadocs)

5.1.1 Core Services

The core services contains interfaces presenting application components required for building applications that make use of the aggregation functionality. These services are encapsulated and documented in the com.yodlee.soap.core package of the server APIs.

This set of core services offers the following functionality through SOAP:

Authentication for Cobrands – To use any of the features of the Yodlee SDK, the cobrand must have a valid context, obtained through authentication. This service is described in CobrandLogin.wsdl

Authentication for Members – To take advantage of user data, users need to be authenticated with the Yodlee SDK. This service is described in Login.WSDL. To access any user-specific features the user must either have a valid context (obtained through calling a login call and caching the resulting UserContext object) or by passing the user credentials along with every call. In the latter case, the user is authenticated in every call prior to executing the call.

User (or Member) management that is inclusive of user registration, certification – Users need to be registered with the Yodlee platform to take advantage of the aggregation functionality. Cobrands may determine a process of certifying users

Chapter 5: API Packaging

Yodlee, Inc. © Copyright 2013 Confidential

5-1

Page 25: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

SOAP Development

5-2

such as making them accept terms and conditions of the service. Certification and registration are both requirements for users to be allowed access to the Yodlee SDK functionality. These services are described in UserRegistration.WSDL and UserCertification.WSDL respectively.

Preference Management for Members – This is a service that helps managing member profile and preference information and is described in UserPreferenceManagement.WSDL

Data Service Management – This is the primary service responsible for enabling retrieval of member aggregated data through the Yodlee SDK APIs and is described in DataService.WSDL.

Refresh – The refresh service handles the mechanism of retrieving the latest information for member items from the destination data sources and is described in Refresh.WSDL.

Site Management – Site Management includes site traversal APIs which would help retrieving different sets of sites and related information for the customer. Popular sites, suggested sites, and matching sites APIs are available under Site management.

Site Account Management – Site account management service APIs are responsible for the process of adding sites, which internally add MemSiteAccount to the Yodlee system. This service also includes APIs to manage MemSiteAccounts.

Item Management – Item management handles addition, editing, and removal of member items through the Yodlee SDK. Addition of member items is required prior to being able to aggregate information for those items through the Yodlee platform. This service is described in ItemManagement.WSDL

Transaction Management – This is the service that handles updating and retrieval of user transactions belonging to member items added through Yodlee SDK. They are further modularized into:

Transaction Search – Transaction search provides functionalities to retrieve user transactions. This service is described in TransactionSearchService.WSDL.

Transaction Management – The transaction management service provides functionality to update, add information, and reconcile user transactions. This service is described in TransactionManagement.WSDL.

Transaction Categorization – Transaction categorization provides facility for manual user categorization/ recategorization and also provides a list of supported transaction categories by the Yodlee platform. This service is described in TransactionCategorizationService.WSDL.

Account Sharing – This service provides functionalities for account sharing. Using this service one can share accounts, un-share accounts, update shared

Chapter 5: API Packaging

Yodlee, Inc. © Copyright 2013 Confidential

Page 26: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

SOAP Development

account settings, get shared account details shared by the user and shared to user, and so on. This service is described in SharedAccountService.WSDL.

5.1.2 Extension Services

The extension set of services corresponds to extensions used by applications interacting with the SDK. These extensions correlate with the com.yodlee.soap.ext package of the Yodlee SDK server APIs. These extensions are pluggable into the Yodlee SDK framework and are designated as extensions since there may be many implementations of these services that may be required to support different kinds of applications.

Extensions are provided for the content service traversal: The ContentServiceTraversal service supports retrieval of all content services supported by the Yodlee SDK as well as filtering by container type. In a typical use case, a user would traverse the supported list of content services to locate the content service that the user desires to add. This service is further described in ContentServiceTraversal.WSDL.

5.1.3 Common Objects

Common objects include data types corresponding to "data" or "value" classes used throughout the Yodlee SDK as arguments and return parameters from APIs that correspond to the com.yodlee.soap.core and com.yodlee.soap.ext packages. These objects are encapsulated in the com.yodlee.soap.common package.

Some important classes that are in this package are:

CobrandContext – CobrandContext is covered in the WSDL documents.

ContentServiceInfo – The ContentServiceInfo class encapsulates information about a specific content service in the Yodlee SDK and has methods to retrieve this information such as which site the service belongs to, the organization the service belongs to, etc. (Refer to the Javadocs: com.yodlee.soap.common.ContentServiceInfo)

Form - Form is the highest-level encapsulation of form data. It is generally used to hold a grouping of FieldInfo instances with the conjunction AND but can be used to hold sub-forms.

FieldInfo:

FieldInfo is a general-purpose parent class that encapsulates a name-value pair setting for a particular field. Subclasses include:

FieldInfoSingle designates a single valued field

FieldInfoMultiFixed designates a multivalued field where the number of values is fixed.

Apart from the name-value pair information, the FieldInfo class supports designating the value/s as being non-editable once set, designating whether the value/s are optional or not, and supports constraining the value/s that can be set to be one from among a specified list of valid values.

5-3Chapter 5: API Packaging

Yodlee, Inc. © Copyright 2013 Confidential

Page 27: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

SOAP Development

5-4

FieldInfoChoice is a grouping of FieldInfo instances with the conjunction OR

ItemSummary – The ItemSummary class encapsulates information about a specific member item such as information on a member's Chase credit card Item. The information in this example would include the unique identifier for the member item, references to content service that the Item belongs to, and the actual Item data, which in this case includes account number, account holder, account open date, amount due, and so forth.

RefreshInfo – The RefreshInfo class encapsulates refreshrelated information for an item that is valid as of the time the instance was created. The refresh information includes the last time the item was refreshed, the status code of this refresh, the refresh type (i.e., whether instant refresh or cache server based refresh etc.)

UserContext – The UserContext is covered in the user context definition document.

5.1.4 Services Overview Diagram

The services overview diagram describes the main services made available through the Yodlee SDK in SOAP mode. It also describes within each service the most important use cases that the service addresses. Terms in this diagram such as item and content service are defined in the Terminology section.

Diagram Details:

Valid Cobrand* indicates a cobrand that is authenticated and uses a valid cobrand context

Valid User* indicates a user who is authenticated and uses a valid user context

Renew Context* indicates extending a valid session or conversation with the Yodlee platform server in order to facilitate further activity

The (*) process block is invoked as a part of the add item process.

Access Account List* returns a list of accounts of the user within the item such as the checking and savings accounts within a banking item

Access Account Details* fetches all account-related information such as account balance, account number etc. for a banking account

Access Account Transaction Details* is a typical level of detail that is made accessible through the Yodlee SDK for banking, credit card accounts, etc. where the transaction history of the account is made available

Chapter 5: API Packaging

Yodlee, Inc. © Copyright 2013 Confidential

Page 28: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

REST Development

5.2 REST Development

This section provides an overview of RESTful services offered by the Yodlee platform. Representational state transfer (REST) relies on a stateless, client-server, cacheable communications protocol and uses the HTTP protocol virtually in all cases.

REST is an architectural style for designing networked applications. Simple HTTP protocol is used to make calls between machines instead of complex mechanisms such as CORBA, RPC or SOAP.

RESTful applications use HTTP requests to post data (create and/or update), read data (make queries), and delete data. Thus, REST uses HTTP for all CRUD (Create/Read/Update/Delete) operations. Any programming language can be used to communicate over HTTP with the REST server.

5.2.1 REST Services

In addition to SOAP services, Yodlee also offers common aggregation and personal finance data in form of RESTful services for easy and quick access.

The following features are offered via RESTful services-

Accounts services – this set of services provides access to consumer's account data for all the account types supported by Yodlee. These APIs also allow editing of account meta-data.

Transaction management – this set of services helps fetch transaction data and allows creation and update of transaction data for different account types and also for manual transactions.

Account group services – this service fetches account groups created by consumers.

5-5Chapter 5: API Packaging

Yodlee, Inc. © Copyright 2013 Confidential

Page 29: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

REST Development

5-6

Save for a Goal – this service allows to create, edit, and delete saving goals. There are 3 versions of this API available, each with increasing complexity and functionality.

CompareMe datapoints – this service allows comparison of a consumer's data with other consumers in his or her location.

In addition, other APIs for user profile, user preferences, internationalization and budgeting are also supported by REST APIs.

For more details about Yodlee REST API refer to Yodlee PersonalFinance FinApp REST API Guide.

5.2.2 Yodlee RESTful Services and OAuth

Access to Yodlee REST services involves OAuth for authorizing the application and for signing of requests. OAuth is an open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.

More details on OAuth can be found at http://oauth.net/

Using Yodlee REST API involves the following steps:

1. Generation of access token – The access token required to sign the URL can be obtained by invoking the following API where bridgetAppId is the unique identifier of the FinApp published for the customer environment for the purpose of launching hosted wizards.

public OAuthAccessToken getOAuthAccessToken(UserContext

userContext, Long bridgetAppId)throws

InvalidUserContextException,

InvalidApplicationIdentifierException,

IllegalArgumentValueException,

InvalidBridgetStatusException

When the consumer exits the application, Yodlee recommends that the access token be invalidated to prevent its misuse via a security attack. The following API invalidates an active access token.

public Boolean invalidateOAuthAccessToken(UserContext

userContext, Long bridgetAppId, String token)

throws

InvalidUserContextException,

InvalidApplicationIdentifierException,

IllegalArgumentValueException,

InvalidAccessTokenException

Chapter 5: API Packaging

Yodlee, Inc. © Copyright 2013 Confidential

Page 30: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

REST Development

2. Generation of REST API URL - the REST API URL can be generated using the URL formats provided for each API in the Yodlee PersonalFinance FinApp REST API Guide.

The following OAuth parameters need to be appended to the REST API URL as URL parameters for signing and security purpose.

oauth_token – this is the generated token.

oauth_consumer_key – this is the client credentials provided by Yodlee as part of the setup for accessing REST APIs and Hosted Wizards.

oauth_signature_method – this signature method is used by Consumer to sign the request. Yodlee uses HMAC-SHA1 for signing. Value of this parameter should be 'HMAC-SHA1'

oauth_signature – this is the signature generated for the URL including OAuth parameters. oauth_signature is set to the calculated digest octet string, first base64-encoded, then URL-encoded.

oauth_timestamp – the timestamp is expressed in the number of seconds since January 1, 1970 00:00:00 GMT. The timestamp value must be a positive integer and must be equal or greater than the timestamp used in previous requests.

oauth_nonce – a nonce is a random string, uniquely generated for each request. The nonce allows the Service Provider to verify that a request has never been made before and helps prevent replay attacks when requests are made over a non-secure channel.

oauth_version – Yodlee uses Oauth version 1.0.

The REST API URL generated can be invoked by the customer application to retrieve data to be used by the application.

References: http://oauth.net/core/1.0

http://hueniverse.com/oauth/guide/intro/

5-7Chapter 5: API Packaging

Yodlee, Inc. © Copyright 2013 Confidential

Page 31: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Chapter 6: Authentication

The Yodlee SDK requires either one or two levels of authentication depending on the mode of application deployment. These are referred to as cobrand and user level authentication. Only after valid authentication at these levels is functionality made available through the APIs.

In the SOAP server scenario, since multiple clients potentially belonging to different customers can share the same server, cobrand-application authentication is enforced. Every cobrand-application pair needs a set of authentication credentials in this scenario.

In Yodlee version 12.0, a cobrand represents a namespace typically unique to a customer. The cobrand authentication process involves submission of valid credentials.

Any operation involving user-aggregated information or user-profile information such as adding new accounts to aggregate, altering the user profile information, or refreshing user account information needs a valid user context as part of user level authentication. The user context object (instance of UserContext data type) is a valid object returned on successful authentication of the user through the Yodlee SDK.

6.1 Cobrand Context

The CobrandContext data type encapsulates information about a cobrand. When deploying in SOAP mode, the context is required for attempting a user login. It is the basis for the Yodlee platform to recognize the cobrand uniquely and to apply customized properties applicable to the cobrand such as the list of content services activated for the cobrand.

In addition to uniquely identifying the cobrand, the context contains the preferred locale of the cobrand and encapsulates the terms and conditions version that is currently used by the cobrand. If the cobrand updates the terms and conditions of the service, users will have to accept the new terms to be certified and granted access to the service. This check is done at the time of login for every user and an exception is thrown for the user being uncertified. The application can determine the action course such as displaying a page of the new terms and conditions for user acceptance.

NOTE: For additional information please refer to the Javadocs com.yodlee.soap.common.CobrandContextin SOAP mode.

6.1.1 Usage of the CobrandContext in the SDK

The CobrandContext is a prerequisite as an input parameter for performing functions such as:

Registration

Certification

Login of users

Chapter 6: Authentication

Yodlee, Inc. © Copyright 2013 Confidential

6-1

Page 32: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

User Context

6-2

Content service traversal (as supported in the com.yodlee.ext.traversal package in the Javadocs and in the ContentServiceTraversal.WSDL web service.)

Obtaining credentials for a content service (in the com.yodlee.core.itemmanagement package in the Javadocs and in the ItemManagement.WSDL Web service.)

All APIs that are not user specific in the platform.

NOTE: Yodlee suggests making a CobrantContext singleton object that is thread safe. A call is made to the getCobrandContext method that is synchronized and either creates a new cobrand context (this operation is thread safe since the method is synchronized) or returns the existing object. Since all Yodlee interaction requires a cobrand context, it is guaranteed that this will always be every thread’s first interaction with Yodlee and guarantee Axis is initialized in a thread-safe model.

6.2 User Context

6.2.1 Overview

User authentication is required for performing functions such as:

Member Item Management - Member item management includes adding, editing, and removing accounts from a user's aggregation profile (as documented in the com.yodlee.core.itemmanagement package in the Javadocs and in the ItemManagement.WSDL Web service.)

Data Service Management - Data service management includes supporting item summary retrieval that is inclusive of fetching data for all user accounts at multiple levels of detail such as item account detail or inclusive of transaction detail (as documented in the com.yodlee.core.dataservice package in the Javadocs as well as in the DataService.WSDL web service.)

Logout, Extending Session or conversation validity, changing login credentials for the service, retrieving allied information on the user's login activity (All of these are documented as in the com.yodlee.core.login package in the Javadocs as well as in the Login.WSDL web service.)

Preference Management at the user and Item level as documented in the com.yodlee.core.preferencemanagement package in the Javadocs as well as in the PreferenceManagement.WSDL Web service.

All Refresh Functionality as documented in the com.yodlee.core.refresh package in the Javadocs as well as in the Refresh.WSDL web service.

Decertification and Un-registering of users as well as updating user's registration profile such as the email as documented in the com.yodlee.core.usermanagement package in the Javadocs as well as in the UserCertification.WSDL and UserManagement.WSDL web services.

Chapter 6: Authentication

Yodlee, Inc. © Copyright 2013 Confidential

Page 33: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

User Context

6.2.2 User Authentication Modes

The Yodlee platform provides two modes of user validation that can be invoked interchangeably by the calling application. In both cases, a user must be authenticated using the credential mode associated with how he was registered - either a username/password or a signed SAML assertion.

Sessionless Authentication - in the sessionless authentication mode, user credentials are passed along with every call and the user is validated each and every time a call is made. This avoids the need to make a separate user login call prior to making any user-specific API requests. It also has the potential to reduce implementation complication on the client side and avoids the overhead of an extra WAN call, which can improve performance when making limited calls for a user.

Each method call using a sessionless core call is slightly slower because it has the extra overhead of validating the credentials. When making successive SDK calls for the same user, it is worthwhile to stick with the login method.

UserContext Authentication - in the UserContext authentication mode, a UserContext is obtained for a user by first calling a login call. This data type encapsulates information about a user who has logged in to the Yodlee platform. This context is required for validating access for a user to the platform and associated user-related functionality. The data type encapsulates a session specific key related to the logged in user's session (i.e., a conversation-specific key).

The return of a valid UserContext instance of the data type during authentication/login means that the user has been granted access to the Yodlee platform and can use this context to perform other user functions.

The conversation credentials encapsulated in the UserContext correspond to an active session on the Yodlee server that exclusively identifies the authenticated, logged-in user. The session becomes inactive as soon as an inactivity timeout elapses. To renew the inactivity timeout, an application must invoke the touchConversation method. Also, following login, the session has an absolute timeout period beyond which the underlying conversation credentials cannot be used. For long running user sessions, the application can call the renewConversation method that returns a new UserContext.

Apart from storing the session or conversation identifier, the context inherits the properties and methods of the CobrandContext data type. The UserContext supports a method to retrieve the session credentials and also supports a method to validate whether the UserContext is valid.

NOTE: For additional information please refer to the Javadocs com.yodlee.common.UserContext as well as to the YodleeTypes.WSDL data type descriptor file.

6-3Chapter 6: Authentication

Yodlee, Inc. © Copyright 2013 Confidential

Page 34: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

User Context

6-4

6.2.3 Including Client IP Address

6.2.3.1 Use Case Excerpt

Tom registers or logs into the system. The IP address that his request originates from is being set before creating his user context so that it can be used to improve security and legal compliance.

6.2.3.2 How to Set the IP Address

When calling a registration or login with the Yodlee system, the API requires a CobrandContext to be passed with the API call to provide information about the request. To include the client IP address for making the call, the CobrandContext should be cloned so that it is thread-safe and then the client IP should be set in the object. The client IP address should be taken from the user's request and set into the CobrandContext object. When the register or login call is made using this cobrand context, the Yodlee system will associate this IP address with the login request.

This should be the best-available client IP address. It may be a public NAT address, or in the case of internal testing this will be an internal address such as "172.16.1.97". If this is a batch process where there is no user presenter, the static address "10.0.0.0" should be used.

ByteArrayOutputStream bos = new ByteArrayOutputStream(); ObjectOutputStream out = new ObjectOutputStream(bos); out.writeObject(cobrandContext);

out.flush();

out.close();

// Make an input stream from the byte array and read // a copy of the object back in.

ObjectInputStream in = new ObjectInputStream(new ByteArrayInputStream(bos.toByteArray()));

CobrandContext localCobrandContext =(CobrandContext)in.readObject();

String clientIP = servletRequest. getRemoteAddr(); localCobrandContext.setIpAddress(clientIP);

Chapter 6: Authentication

Yodlee, Inc. © Copyright 2013 Confidential

Page 35: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Default Timeout Values

6.3 Default Timeout Values

Table 6-1: Default timeout values

Property Value Time Description

com.yodlee.core.login.cobrand_session_timeout 6000 100 min Cobrand context session timeout.

com.yodlee.core.login.time_to_lock_login 7200 120 min User context timeout.

com.yodlee.core.login.relative_time_to_lock_login

1800 30 min The maximum idle time after which the session is timed out.

com.yodlee.core.login.cobrand_max_login_failure_tolerance

5 NA Count of cobrand login lock out.

com.yodlee.core.login.max_login_failure_tolerance

7 NA Count of user login lock out.

com.yodlee.core.login.max_failed_reauthentication_attempts

3 NA The maximum number of attempts that can be made for pin based authentication.

6-5Chapter 6: Authentication

Yodlee, Inc. © Copyright 2013 Confidential

Page 36: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Chapter 7: Data Concepts

This chapter describes the logical data model of the Yodlee platform and the relationships between the various significant data concepts.

7.1 Users and Sessions

Users are represented as member objects within the system. Every cobrand has a unique user namespace and a unique set of members identified by their usernames. The member object stores credential information such as a password. The member identifier is referentially linked to member preference information that can contain arbitrary information related to that user such as member-specific Web application display preferences and application artifacts such as password recovery questions associated with a member's password credentials.

Member credentials are required to authenticate a user with the Yodlee platform. Additional information such as whether a user needs to be authenticated by an external source (such as an external SAML server) is also stored.

Associated with each member there may be zero or one session. A session is created when a user is authenticated by the platform (no session is created in the sessionless authentication mode). Each session has a 'SessionID', which is a string that ensures, within mathematically acceptable limits, that valid session IDs cannot be guessed. A session ID of an active session can be used for authentication in lieu of username and password in follow-up method invocations. Associated with each session is a session longevity period after which that session is no longer valid for authentication. This feature enhances security of end-user access, and is configurable by Yodlee.

7.2 Data Providers

An organization is a logical entity that typically represents an organization in the real world that may be a provider of aggregated data like a bank or a brokerage.

An organization may be divided into several destinations or sites. Real world representations of sites could be the collection of websites supported by a major financial institution (e.g., regional online banking websites).

Each site can have one or more content services associated with it, which are internal Yodlee representations of sites divided among data categories (e.g., bank, credit card, investment, loan, etc.). The content services associated within a site may or may not require the same set of user credentials.

When a user adds an instance of a content service, the resulting aggregated data may contain one or multiple accounts. To aggregate all accounts for a user associated with an organization, it may be necessary to add multiple content services.

Chapter 7: Data Concepts

Yodlee, Inc. © Copyright 2013 Confidential

7-1

Page 37: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Data Classification

7-2

7.3 Data Classification

A container defines how data collected by the Yodlee platform on behalf of users (aggregated data) is classified after normalization. Examples of containers include Investment, Banking, and Credit Card. Every type of data retrieved from an aggregated content service is associated with a specific container. Every container is also associated with a financial asset type such as asset, liability, or neither.

A data service type is a logical real world grouping of data. Every container has a one-to-many mapping with data service types. For example, the data service type Investment describes the data related to the container Investment. Additional data service types called Holding, Transaction and Statement describe the data related to these kinds of real world constructs and are also associated with the Investment container. Please refer to the following package in the com.yodlee.core package in the Javadocs for a complete list of data service types.

com.yodlee.core.dataservice.types. For SOAP mode, these types are defined in DataService.WSDL.

A content service represents a relationship between a container and a specific site. Each content service corresponds to exactly one site and one container but sites and containers may be associated with multiple content services, respectively. Examples of content services include Bank Of America Checking, Scottrade Investment, and IQBank Credit Card. An instance of a content service collection that has a one-to-one correspondence with a member is referred to as an item.

While an item represents an instance of content service aggregated data for a particular member, it may not map directly to the real world representation of accounts the way a user typically thinks of them. For example, if a user has several credit card accounts at IQBank, the content service IQBank Credit Card would be used to aggregate appropriate data for that user. This instance of aggregation would be associated with an item and have a unique identifier. However, the data aggregated would apply to both accounts and needs to be further filtered in order to represent how a user expects to access it - by credit card account. This further classification of item data by the real world account is referred to as an item account.

It is relevant to note that there may be more than one instance for a given item. For example, if a user adds the same Chase Card account more than once, an item will be created for each instance of this content service/member combination. For each item, the date/time at which the data was obtained from the service as well as a status code detailing the success/failure/cause of the data gathering operation is recorded.

7.4 Data Service Optimizations

The data service APIs are some of the most powerful APIs at Yodlee and have the ability to return large amounts of data beyond what a client may be capable of processing. When working with Web services, requests are packaged in SOAP XML. While XML is extremely good at cleanly structuring data and providing human-readable contents, it is a very bloated messaging format. This means that service calls returning large amounts of

Chapter 7: Data Concepts

Yodlee, Inc. © Copyright 2013 Confidential

Page 38: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Data Service Optimizations

data can become huge packages of XML data. Care must be taken when calling data service APIs not to request too much data at a single time.

If too much data is requested depending on the client side Web service technology used, OutOfMemory errors may be thrown as it attempts to parse the XML message back into objects.

7.4.1 Split Calls

While it is possible to request all user data in a single call, this will quickly lead to packages of data too large to be parsed. There is a round of optimization that should occur based on the use cases needed to request the right amount of data for the user. In general, the preferred use case is a call to get summary-level information for all the accounts followed by individual calls per account to retrieve account-level data as required.

7.4.2 Data Extents and Summary Calls

When making requests to data services APIs in the Yodlee SDK, there is the ability to pass data extent objects with the call that specify how much information to return. If none are passed, Yodlee will return all data extents for the request. Each container supports data extents ranging from 0 to a specific positive number. The higher the data extent level number, the higher the level of data returned.

NOTE:

Data extents higher than level 0 should not be set as a significant amount of data will be retrieved which will reduce the API performance. Specifying 0 as the data extent level is sufficient to retrieve account level information.

DataExtent.endLevel(Integer.MAX_VALUE) should not be set as this would retrieve all account level details.

Yodlee recommends fetching transactions by using item summary with data extent level 0 or use the transaction search with a date range. For more information refer to Yodlee PersonalFinance SDK Implementation Guide.

The following piece of code creates a SummaryRequest object that contains only the highest level data extents for the user for all the containers. This type of summary request is useful to gather data for an accounts overview page:

String[] containerTypes = {"bank",

"credits",

"stocks",

"loans",

"miles",

7-3Chapter 7: Data Concepts

Yodlee, Inc. © Copyright 2013 Confidential

Page 39: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Data Service Optimizations

7-4

"mortgage"};

DataExtent bankExtents = new DataExtent(0,0);

DataExtent ccExtents = new DataExtent(0,0);

DataExtent invExtents = new DataExtent(0,0);

DataExtent loanExtents = new DataExtent(0,0);

DataExtent rewardExtents = new DataExtent(0,0);

DataExtent mortgageExtents = new DataExtent(0,0);

DataExtent[] dataExtents = {

bankExtents,

ccExtents,

invExtents,

loanExtents,

rewardExtents,

mortgageExtents

};

SummaryRequest summary = new SummaryRequest(containerTypes, dataExtents);

For further details on the data extents supported for each containers, refer to the following

sections of Javadocs:

com.yodlee.soap.core.dataservice.types.BankData

com.yodlee.soap.core.dataservice.types.BillPayServiceData

com.yodlee.soap.core.dataservice.types.BillsData

com.yodlee.soap.core.dataservice.types.CardData

com.yodlee.soap.core.dataservice.types.InsuranceData

com.yodlee.soap.core.dataservice.types.InvestmentData

com.yodlee.soap.core.dataservice.types.RewardPgm

Chapter 7: Data Concepts

Yodlee, Inc. © Copyright 2013 Confidential

Page 40: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Data Service Optimizations

com.yodlee.soap.core.dataservice.types.PrepayAccountData

com.yodlee.soap.core.dataservice.types.Loan

com.yodlee.soap.core.dataservice.types.TaxData

com.yodlee.soap.core.dataservice.types.OtherAssetsData

com.yodlee.soap.core.dataservice.types.OtherLiabilitiesData

7.4.3 Data Service Lite

The Yodlee data objects have far more fields associated with them than are used by most applications. For every field sent there is additional space taken up inside the SOAP call being returned. Yodlee has the concept of data service lite that will restrict the fields being returned to only include the most commonly used fields. Additional fields will be blank and are not returned.

SummaryRequest.setDataServiceLite(true);

Customers cannot set or change what fields are filtered by this property. The list of field filtered also varies by the container for which the customer is requesting data.

7.4.4 Content Service Info

When making requests for data from the data service APIs, the accounts return will encapsulate information about the content service related to the account. Most partners choose to do a daily or monthly sync of content service information to a local database and do not need it returned with each call into the data services APIs. Therefore it is often helpful to turn off the return of the content service information with the request.

SummaryRequest.setContentServiceInfoRequired(false);

7.4.5 Transaction Search Service

When making requests to the TransactionSearch service APIs in the Yodlee SDK, there is a search filter is passed to reduce the amount of data collected on the server and returned in the response. When showing data to a consumer make sure the search filter is as restrictive as possible for data to be shown to allow all filtering to occur on the server side at Yodlee.

The most important filter is the search time period which should generally be limited to a maximum of 30 days when retrieving a list of recent transactions. If the consumer later decides to view transactions older than 30-days a subsequent transaction search can be executed for an earlier time.

7-5Chapter 7: Data Concepts

Yodlee, Inc. © Copyright 2013 Confidential

Page 41: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

dataservice.type to ContainerName Mapping

7-6

7.5 dataservice.type to ContainerName Mapping

The following table illustrates the relationship between the ContainerName and dataservice.type for the most popular containers.

Table 7-2: Relationship between the ContainerName and dataservice.type

Description ContainerNamedataservice.type (top

class)Class (asset/

liability)

Auction Auction AuctionLoginAccountData

Bank Bank BankData Asset

Bill Payment bill_payment BillPayServiceData Liability

Bills - Minutes Minutes BillsData Liability

Bills - Bills Bills BillsData Liability

Bills - Telephone Telephone BillsData Liability

Bills - Utilities Utilities BillsData Liability

Bills - Cable and Satellite cable_satellite BillsData Liability

Calendar Calendar CalendarData Neither

Charts Charts ChartData

Chats Chats ChatData Neither

Consumer Guide consumer_guide ConsumerGuideData Neither

Credit Cards Credits CardData Liability

Deals Deal DealData

Hotel Reservations hotel_reservations HotelReservationsData Neither

Insurance Insurance InsuranceLoginAccountData

Liability

Loans - Loans Loans LoanLoginAccountData Liability

Loans - Mortgage Mortgage LoanLoginAccountData Liability

Message Boards Messageboards MessageBoardData Neither

Miles Miles RewardPgm

Real Estate RealEstate HomeValueAccountData Asset

Reservations - Travel Travel AirReservationData Neither

Reservations - Reservations Reservations ReservationData Neither

Investments Stocks InvestmentData Asset

Tax Tax TaxData Liability

Chapter 7: Data Concepts

Yodlee, Inc. © Copyright 2013 Confidential

Page 42: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Entity Relationship Diagram

7.6 Entity Relationship Diagram

The following diagram provides a high level overview of the relationships between various data model concepts.

7-7Chapter 7: Data Concepts

Yodlee, Inc. © Copyright 2013 Confidential

Page 43: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Dataservice.type Class Hierarchy

7-8

7.7 Dataservice.type Class Hierarchy

The following diagrams illustrate the class relationships for commonly used dataservice.types.

7.7.1 BankData

7.7.2 BillPayServiceData

Chapter 7: Data Concepts

Yodlee, Inc. © Copyright 2013 Confidential

Page 44: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Dataservice.type Class Hierarchy

7.7.3 BillsData

7.7.4 CardData

7-9Chapter 7: Data Concepts

Yodlee, Inc. © Copyright 2013 Confidential

Page 45: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Dataservice.type Class Hierarchy

7-10

7.7.5 DealData

7.7.6 HotelReservationsData

7.7.7 InvestmentData

Chapter 7: Data Concepts

Yodlee, Inc. © Copyright 2013 Confidential

Page 46: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Dataservice.type Class Hierarchy

7.7.8 InsuranceLoginAccountData

7-11Chapter 7: Data Concepts

Yodlee, Inc. © Copyright 2013 Confidential

Page 47: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Dataservice.type Class Hierarchy

7-12

Chapter 7: Data Concepts

Yodlee, Inc. © Copyright 2013 Confidential

Page 48: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Dataservice.type Class Hierarchy

7.7.9 LoanLoginAccountData

7-13Chapter 7: Data Concepts

Yodlee, Inc. © Copyright 2013 Confidential

Page 49: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Dataservice.type Class Hierarchy

7-14

7.7.10 OrdersData

7.7.11 RewardsPgm

7.7.12 Real Estate

Chapter 7: Data Concepts

Yodlee, Inc. © Copyright 2013 Confidential

Page 50: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Class Hierarchy for MFA

7.7.13 TaxData

7.8 Class Hierarchy for MFA

7.8.1 MFA Refresh Info

7-15Chapter 7: Data Concepts

Yodlee, Inc. © Copyright 2013 Confidential

Page 51: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Class Hierarchy for MFA

7-16

7.8.2 MFA User Response

7.8.3 MFA Question Answer

Chapter 7: Data Concepts

Yodlee, Inc. © Copyright 2013 Confidential

Page 52: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Chapter 8: Implementation of SDK Functions

The following sections provide more detailed insight into implementation of select Yodlee SDK functions.

8.1 Gzip Compression

The Yodlee SDK servers support gzip compression of all communication. Enabling gzip in the client-side has large benefits in terms of reducing the amount of data being sent and improving performing due to less bandwidth utilization.

Important! Yodlee strongly recommends using gzip, although it is not mandatory. Bandwidth consumption may be up to 800% greater when gzip is not used.

All SDK messages sent to Yodlee using gzip compression should include Content-Encoding: gzip as the request headers. For the Yodlee SDK server to return the response as gzip encoded, the request header must additionally include Accept-Encoding: gzip. The method for enabling gzip is specific to the client-side soap libraries used such as Apache Axis or .NET.

For example with Apache Axis 1.4, the Axis client needs to be configured to use the CommonsHTTPSender in client-config.wsdd and then the service or call object must have the following properties set:

((org.apache.axis.client.Stub)dataService)._setProperty(HTTPConstants.MC_ACCEPT_GZIP, Boolean.TRUE);

((org.apache.axis.client.Stub)dataService)._setProperty(HTTPConstants.MC_GZIP_REQUEST, Boolean.TRUE);

8.2 Web Services Security (WS-Security)

Yodlee allows SOAP messages to be signed and encrypted with an X.509 certificate. Clients making Web service calls to Yodlee must sign the body of the SOAP message and then encrypt the message with a Yodlee public certificate. An authorized signatory at Yodlee will sign the body of the SOAP message in the response and encrypt the message with the client's public certificate. For this purpose, clients should provide their public certificate to Yodlee.

NOTE:

It has been observed during Yodlee certification that there is degradation in performance of the SDK when WS security is also included.

Enabling WSSE adds message encryption to all communications between the client and the server. The asymmetric encryption used by WSSE adds a large amount of processing overhead on both the client and the server. When

Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

8-1

Page 53: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Web Services Security (WS-Security)

8-2

running a system with WSSE enabled, each API call to Yodlee typically runs 2-5 times slower.

Yodlee recommends only using SSL for channel encryption of the message. Using only SSL will provide authentication of the Yodlee server based on an SSL certificate and Yodlee identifies the client based on source IP address as well as login credentials. All packets are encrypted at the socket layer.

The standard policy for signing and encrypting such messages is as follows:

<wsp:Policy wsu:Id="SignEncr" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">

<wsp:ExactlyOne>

<wsp:All>

<sp:AsymmetricBinding xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">

<wsp:Policy>

<sp:InitiatorToken>

<wsp:Policy>

<sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"/>

</wsp:Policy>

</sp:InitiatorToken>

<sp:RecipientToken>

<wsp:Policy>

<sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">

<wsp:Policy>

<sp:RequireThumbprintReference/>

</wsp:Policy>

Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 54: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Web Services Security (WS-Security)

</sp:X509Token>

</wsp:Policy>

</sp:RecipientToken>

<sp:AlgorithmSuite>

<wsp:Policy>

<sp:TripleDesRsa15/>

</wsp:Policy>

</sp:AlgorithmSuite>

<sp:Layout>

<wsp:Policy>

<sp:Strict/>

</wsp:Policy>

</sp:Layout>

<sp:IncludeTimestamp/>

<sp:OnlySignEntireHeadersAndBody/>

</wsp:Policy>

</sp:AsymmetricBinding>

<sp:SignedParts xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">

<sp:Body/>

</sp:SignedParts>

<sp:EncryptedParts xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">

<sp:Body/>

8-3Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 55: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Web Services Security (WS-Security)

8-4

</sp:EncryptedParts>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

Sample request for the Cobrand login API call:

<?xml version='1.0' encoding='UTF-8'?>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">

<soapenv:Header>

<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1">

<wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Timestamp-1">

<wsu:Created>2009-11-16T23:36:12.794Z</wsu:Created>

<wsu:Expires>2009-11-16T23:41:12.794Z</wsu:Expires>

</wsu:Timestamp>

<xenc:EncryptedKey Id="EncKeyId-3CBCDFDB62B393A18312584145742325">

<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />

<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<wsse:SecurityTokenReference>

<wsse:KeyIdentifier EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-

Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 56: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Web Services Security (WS-Security)

1.1#ThumbprintSHA1">D7YhWcuiV2kZdQ/sqKhvR+CUQ1Q=</wsse:KeyIdentifier>

</wsse:SecurityTokenReference>

</ds:KeyInfo>

<xenc:CipherData>

<xenc:CipherValue>EOHr5HLkNwwU4OkTOius+tr4GkC/SuLHFQnNaBOXELYyz+54JKclBi6lvkajXBOVOpEypP8Q6tdeJXO3AXzGzepkdqKHLyWQXOKeaI3qUlkbQP8FhOZW8QAqaftnmVJTYYGorCOX3tgwDkaFuyJOffJLg+L9kI6igGnRBxegfTg=</xenc:CipherValue>

</xenc:CipherData>

<xenc:ReferenceList>

<xenc:DataReference URI="#EncDataId-3" />

</xenc:ReferenceList>

</xenc:EncryptedKey>

<wsse:BinarySecurityToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="CertId-3CBCDFDB62B393A18312584145728731">MIICHDCCAYUCBEqMbNQwDQYJKoZIhvcNAQEEBQAwVTELMAkGA1UEBhMCQ0ExCzAJBgNVBAgTAkNBMQwwCgYDVQQHEwNSV1MxDzANBgNVBAoTBkNsaWVudDEOMAwGA1UECxMFTGllbnQxCjAIBgNVBAMTAUMwHhcNMDkwODE5MjEyMTI0WhcNMDkxMTE3MjEyMTI0WjBVMQswCQYDVQQGEwJDQTELMAkGA1UECBMCQ0ExDDAKBgNVBAcTA1JXUzEPMA0GA1UEChMGQ2xpZW50MQ4wDAYDVQQLEwVMaWVudDEKMAgGA1UEAxMBQzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyMu2y0odUZUnEZdZxDOtGs/b92559rQwwwnUOUYZ9FPD+n7Qvj9lxRuXnxfSD01X8Df92qzfPwjBDkLhk8wCYCj/7E50FxziQ5w1jC3YswXrwjcZdEhvg5BLcA0/CVQsoBgdgsbr5a8dq32TEElIqBtvQWxAd5+kgbvLS/KD79ECAwEAATANBgkqhkiG9w0BAQQFAAOBgQDF+jTCJXViHHiZiyNw2CSGTZLTT/JEYhuoBqr0F+83ZK/qLwUw6n8EXR0p0jLqeqUqnemccyrTSg0epgkS41Sn2TX/sPZgPChAaQA8D7tDCLSz89Rl6WcaPZ6KzigCafC1vo0eLfoQtAiCTWtg5eKtJ72+mDDRMwEB6dgLrZX9+A==</wsse:BinarySecurityToken>

8-5Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 57: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Web Services Security (WS-Security)

8-6

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature-2">

<ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />

<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />

<ds:Reference URI="#Timestamp-1">

<ds:Transforms>

<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />

</ds:Transforms>

<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />

<ds:DigestValue>wKFXnNCJtYEb9Ujvj+Cl0bR1niw=</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue>EfYuF5pz+wH4wf616Y70kq4320QtF9mpCH1kfvf7XpInWsMQGAm1OUO1p/JbXejA3XAWbw1YThmM++7HMvCL3wqDEEtnddlkE2sszD+kmPMQlAg1AJNmb+62g1cpkx+XgKlwAohCdA/0zlAZSe9OzxTcr4SEhZ/efwNpf3exZuY=</ds:SignatureValue>

<ds:KeyInfo Id="KeyId-3CBCDFDB62B393A18312584145728882">

<wsse:SecurityTokenReference xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="STRId-3CBCDFDB62B393A18312584145728883">

<wsse:Reference URI="#CertId-3CBCDFDB62B393A18312584145728731" ValueType="http://docs.oasis-

Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 58: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Web Services Security (WS-Security)

open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" />

</wsse:SecurityTokenReference>

</ds:KeyInfo>

</ds:Signature>

</wsse:Security>

</soapenv:Header>

<soapenv:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Id-4587712">

<xenc:EncryptedData628 Id="EncDataId-3" Type="http://www.w3.org/2001/04/xmlenc#Content">

<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />

<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<wsse:SecurityTokenReference xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

<wsse:Reference URI="#EncKeyId-3CBCDFDB62B393A18312584145742325" />

</wsse:SecurityTokenReference>

</ds:KeyInfo>

<xenc:CipherData>

<xenc:CipherValue>n+6qEaOHnqbdxkB+ZHhBxkyELXsnjHBf02wrjKmjx8hyu1lGZyllpA303nkJBAb8AWjPpgcA5tanANO64cgUSgm6y9IZc4HnWixYn72CKg6U4EgpjY5nHyfxWeDKRBuEPGo0fwco7w0mMKXrulnQmA/oilwFS1EozPRtLciUw7HDLEGTCiefnqDkEOfc9LaL8Amdvpyz4VZhmWcrq8tUjJ3NhNZscfLCYpBVK33+mPFiSb+hODzHEHNu2bO7DQNkAuCFUHi5c6T+YT2YrQrWEt63tRb56PAk5LfXR8kFjgqcvMlWlJ9Xe5g8cs9eBfiv0YMv6faSvshEe8RmVTbj2P56Gy

8-7Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 59: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Account Management

8-8

8hL2vECIBpvbXqJjfzEJR76ZWJY8Kv6j+EX1ZMvYXBSR8nm2Mw+KNFt3dBOeK9Cpmh/QHduJqB1z3y0Lb3nBXwyPkigUCUKwe1DqvEGYlBurVAu7l7GXal8Z4H831GoUcVWWDT1SP9Yydm7daZnpDt22uPOmqv/7YA5o1pFcbLGAr4F8IbRiRwIdbW46BxlwxeOoa6SsNon72d/CejG16Z2W/RDdTbH3z+DhbmDaH33TGOYxFjL3M7bPTo+BUwQLn+Sq7fARIamZ835eE4UYiZrAc/D/3N03qMpTqpYyczpahO5UTX74598gD61z0xIABs6fERsQk3Ah0iS86QLT/0kAvv12LWMfslADy7WL/W2GJBcsbSL3+aw5MWdseCIryn9eVL7y0ChkGlYXsAiKcrDc2AawRqQ31d5ClrBctEg2GeHjh5pr16VElVUViH504K8QoNMzN6EQIlBepHz4LaH2BGU1Fxq7fTwmAgTb7okPdEa9RVn6raXgrD5R1L14tqG96R2/JDIuQRnfd5OP+V63wvk3a2GPFsv8P+ztBM57x/4jDm+E2TTN42vEx0BLIZyw2wdu635CRa9SETHwDc29WWrY7bK7lKXnoun2eZjfylG9e79soB45noOrIWrz0pl0ZB</xenc:CipherValue>

</xenc:CipherData>

</xenc:EncryptedData>

</soapenv:Body>

</soapenv:Envelope>

8.3 Account Management

This section describes account management with the Yodlee SDK. It covers adding or editing accounts and auto-registration for a new account.

Sites vary in terms of the set of credential information required for authentication and registration. Yodlee maintains a set of metadata describing the information required by the forms of each site. For example, one site may require just a user name and password while others may require three or more fields including such things as SSN, phone number, or address. Yodlee continuously updates the metadata associated with a site to ensure that applications always have access to the relevant set of fields for a particular site.

To add or edit a site, or auto register a new site requires retrieving the metadata describing the required fields for the site and often presenting them to the user in a form so the user may enter the proper information.

The form metadata is a structured collection of FieldInfo objects. Each required FieldInfo object should have its value set with the appropriate value and a list of these objects is passed into the final call.

8.3.1 Adding a Site

To retrieve the set of fields required for login to a particular site, the following method should be called:

Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 60: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Account Management

SiteAccountManagement.getSiteLoginForm

This returns a Form object containing the metadata that must be provided to properly authenticate the user at the site.

After setting the values on all appropriate FieldInfo objects the site and the accounts associated with it are added with the following method call:

SiteAccountManagement.addSiteAccount

SiteAccountManagement service is described in SiteAccountManagement WSDL

8.3.1.1 MFA Content Services

For MFA content services, startRefreshOnAddition should be set as false while making an addItem call.

8.3.2 Editing Account Credentials

To retrieve the set of fields required for login to a particular site, including the information the user had previously entered into the login form, the following method should be called:

SiteAccountManagement.getSiteAccountCredentials

This returns a Form object containing the metadata that must be provided to properly updated credentials. Additionally, the FieldInfo objects contained in this Form may be used to retrieve the information the user currently has stored.

The current stored values of each FieldInfo may not be directly accessed. Only the HTML-escaped versions may be access using the helper class EscapedFieldInfoHelper. This ensures that any previously entered user value will not cause errors within an HTML page and also removes the vulnerability of a cross-site scripting attack.

After setting the new values on all appropriate FieldInfo objects the site is updated with the following method call:

SiteAccountManagement.updateSiteAccountCredentials

8.3.3 Form Data Structure

When calling account management APIs the first step is always to retrieve the Form object that contains a structure of metadata describing the information the site is expecting for the process.

There are three types of objects that compose Form metadata:

1. Form - The main Form object itself that contains all the additional fields. A Form object contains an array of FormComponent objects that may also be Forms. It also contains a conjunction operator indicating if the contained FormComponent objects are joined by OR or AND operations.

2. FieldComponent - Objects that represent actual fields where data is requested.

8-9Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 61: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Account Management

8-10

3. FieldInfoChoice - A list of FieldInfo objects where only one of the objects is required. This is referred to as an OR conjunction.

Most Form objects are simple. They contain the AND conjunction and a list of FieldInfo objects. Simple OR conjunctions, such as entered a user id or phone number, are handled by a FieldInfoChoice.

Fig. 8-1: Form component inheritance chart

Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 62: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Account Management

Fig. 8-2: Form component relationship chart

8.3.3.1 FieldType

FieldInfoSingle and FieldInfoMultiFixed contain a method getFieldType to return a FieldType object for the fields. FieldType is an enumeration of the different types of form fields and should be used to determine how to render the result.

8.3.3.2 FieldInfoSingle

A FieldInfoSingle is a field with only one element. The element can either be a text box or a list of possible choices.

Table 8-3: HTML rendering for FieldType

FieldType HTML Rendering

FieldType.LOGINFieldType.URLFieldType.TEXT

<input type="text" … />

FieldType.CHECKBOX <input type="checkbox" … />

FieldType.OPTIONS <select … > <option … /></select>

FieldType.PASSWORD <input type="password" … />

FieldType.RADIO <input type="radio" … ><input type="radio" … >

8-11Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 63: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Account Management

8-12

8.3.3.2.1 Text Box

A FieldInfoSingle is a field with only one element. The most common case is a simple text box because most sites ask for only a user and password. The following example shows the Login Form for Wells Fargo (ServiceId 5).

Fig. 8-3: Sample login form

Form

+- conjunctionOperator = AND

+- components

+- FieldInfoSingle, displayName = Username/SSN

+- FieldInfoSingle, displayName = Password

Note that Wells Fargo has 2 FieldInfoSingles that are both text boxes. One is for the username and the other is for the password. You'll see that the password is listed twice. The Yodlee API does not require you to pass the password back twice. This is done optionally to try and catch an error in the user's entry before passing the data to Yodlee.

Question: How do I know the size and max length?

Answer: Yodlee uses a size of 20 and a max length of 40.

The following example shows what the HTML login form for Wells Fargo looks like.

<form>

Wells Fargo Bank Username/SSN: <input type="text" name="LOGIN" value="" size="20" maxlength="40" />

<br />

Wells Fargo Bank Password: <input type="password" name="PASSWORD" value="" size="20" maxlength="40" />

Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 64: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Account Management

Verify Password: <input type="password" name="PASSWORD2" value="" size="20" maxlength="40" />

<br />

</form>

8.3.3.2.2 Drop Down

A FieldInfoSingle can be a drop down list. Figure 2, shows the login form for AMSouthBank (ServiceId 12632).

Fig. 8-4: Sample login form with drop down list

Form

+- conjunctionOperator = AND

+- components

+- FieldInfoSingle, displayName = State

+- FieldInfoSingle, displayName = Social Security # or Tax ID #

+- FieldInfoSingle, displayName = Password or PIN

AmSouthBank has 3 fields. The first field is a FieldInfoSingle drop down list for state. The second field is a text field of type TEXT for Social Security # or Tax ID#. The final field is a text field of type PASSWORD for the bank Password or PIN. Note that this field of type PASSWORD is repeated. This is only to catch user error and not required by the Yodlee API.

The following example shows what the HTML login form for AmSouthBank looks like.

<form>

8-13Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 65: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Account Management

8-14

State: <select name="LOGIN2" >

<option values=="0001" >Alabama</option>

<option values=="0092" >Florida</option>

<option values=="0060" >Georgia</option>

<option values=="0053" >Kentucky</option>

<option values=="00012" >Louisiana</option>

<option values=="00013" >Mississippi</option>

<option values=="00532" >Tennessee</option>

<option values=="00533" >Virginia</option>

</select>

<br />

Social Security # or Tax ID #: <input type="text" name="LOGIN" value=""SIZE="20" maxlength="40" />

</br>

Password or PIN: <input type="PASSWORD" name="PASSWORD" value=""SIZE="20" maxlength="40" />

<br />

</form>

8.3.3.3 FieldInfoMultiFixed

A FieldInfoMultiFixed is a field with 2 or more elements. The elements can either be a text box, drop down list or a mix of both.

8.3.3.3.1 Text Box

The following example shows the login form for Sallie Mae (ServiceId 3805)

Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 66: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Account Management

Fig. 8-5: Sample login form

Form

+- conjunctionOperator = AND

+- components

+- FieldInfoMultiFixed, displayName = Social Security Number

+- FieldInfoSingle, displayName = Password

The following example shows what the HTML login form looks like.

<form>

Social Security Number: <input type="TEXT" NAME="LOGIN" value=""SIZE="4" MAXLENG

TH="40" />

<input type="TEXT" NAME="LOGIN2" value=""SIZE="4" MAXLENGTH="40" />

<input type="TEXT" NAME="LOGIN3" value=""SIZE="4" MAXLENGTH="40" />

<br />

Password: <input type="PASSWORD" NAME="PASSWORD" value=""SIZE="20" MAXLENGTH="40

" />

<br />

</form>

8-15Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 67: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Account Management

8-16

8.3.3.3.2 Drop Down

The following example illustrates Alamo Rent-A-Car (ServiceId 12632)

Fig. 8-6: Sample drop down list

Form

+- conjunctionOperator = AND

+- components

+- FieldInfoSingle, displayName = Confirmation #

+- FieldInfoMultiFixed, displayName = Pickup Date

+- FieldInfoSingle, displayName = Last Name

The following example shows what the HTML login form looks like.

<form>

Confirmation #: <input type="TEXT" NAME="LOGIN" value=""SIZE="20" MAXLENGTH="40" />

</br>

Last Name: <input type="TEXT" NAME="LOGIN2" value=""SIZE="20" MAXLENGTH="40" />

</br>

Pickup Date: <select name="LOGIN3" >

<option values=="APR-2003" >APR-2002</option>

<option values=="AUG-2003" >AUG-2002</option>

<option values=="DEC-2002" >DEC-2001</option>

<option values=="FEB-2003" >FEB-2002</option>

<option values=="JAN-2003" >JAN-2002</option>

Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 68: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Account Management

<option values=="JUL-2003" >JUL-2002</option>

<option values=="JUN-2003" >JUN-2002</option>

<option values=="MAR-2003" >MAR-2002</option>

<option values=="MAY-2003" >MAY-2002</option>

<option values=="NOV-2002" >NOV-2001</option>

<option values=="OCT-2002" >OCT-2001</option>

<option values=="SEP-2002" >SEP-2001</option>

</select>

<select name="LOGIN4" >

<option values=="1" >1</option>

<option values=="10" >10</option>

<option values=="11" >11</option>

<option values=="12" >12</option>

<option values=="13" >13</option>

<option values=="14" >14</option>

<option values=="15" >15</option>

<option values=="16" >16</option>

<option values=="17" >17</option>

<option values=="18" >18</option>

<option values=="19" >19</option>

<option values=="2" >2</option>

<option values=="20" >20</option>

<option values=="21" >21</option>

<option values=="22" >22</option>

<option values=="23" >23</option>

<option values=="24" >24</option>

<option values=="25" >25</option>

<option values=="26" >26</option>

<option values=="27" >27</option>

8-17Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 69: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Account Management

8-18

<option values=="28" >28</option>

<option values=="29" >29</option>

<option values=="3" >3</option>

<option values=="30" >30</option>

<option values=="31" >31</option>

<option values=="4" >4</option>

<option values=="5" >5</option>

<option values=="6" >6</option>

<option values=="7" >7</option>

<option values=="8" >8</option>

<option values=="9" >9</option>

</select>

</br>

</form>

8.3.3.4 FieldInfoChoice

A FieldInfoChoice is used to hold multiple FieldInfo sub-objects where only one is required to complete the form. The following form is from Amica Insurance (ContentServiceId 3787).

Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 70: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Account Management

Fig. 8-7: Form with multiple FieldInfo sub-objects

+- conjunctionOperator = AND

+- components

+- FieldInfoChoice

+- conjunctionOperator = OR

+- components

+- FieldInfoSingle, displayName = Account Number

+- FieldInfoSingle, displayName = Password

+- FieldInfoMultiFixed, displayName = Policy Number

8.3.3.5 Sub-Form

A Form object with multiple Form objects inside joined by an OR conjunction indicates a block of FormComponents where only one set is required. The following form is from Wachovia (ContentServiceId 2022).

Fig. 8-8: Form with multiple form objects

Form

+- conjunctionOperator = OR

8-19Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 71: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Account Management

8-20

+- components

+- Form

+-conjectionOperator = AND

+-components

+-FieldInfoSingle, displayName = USER ID

+-FieldInfoSingle, displayName = PASSWORD

+- Form

+-conjectionOperator = AND

+-components

+-FieldInfoSingle, displayName = CUSTOMER ACCESS NUMBER

+-FieldInfoSingle, displayName = PIN

+-FieldInfoSingle, displayName = CODEWORD

The following example shows what the HTML login form looks like.

8.3.3.6 FieldInfoMultiVariable

FieldInfoMultiVariable is currently not used by the Yodlee SDK.

8.3.4 Helping the User Enter Correct Values

Form entry, especially for auto registration, may request a large number of complex information from the user. There are multiple methods exposed in the API to assist a user enter the proper information to reduce the chances of a user error.

8.3.4.1 Help Text

FieldInfo objects contain a method getHelpText that returns help text associated with a field. This may contain additional validation instructions or other useful information that will aid a user in knowing what to enter.

Below is a snippet of an AutoReg form for AT&T Residential (ContentServiceId 447) where the HelpText is displayed to the right of each field.

Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 72: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Account Management

Fig. 8-9: Sample help text

8.3.4.2 Validation Rules

FieldInfo objects may also have an array of FieldInputValidationRule objects associated with them. These objects contain a regular expression the FieldInput must map to and an error message to be displayed if the field does not match the regular expression.

The Yodlee SDK does not validate these expressions. This information is provided to allow an application to perform its own validation, such as JavaScript validation, before passing the values to the SDK.

8.3.4.3 User Profile Mapping Expressions

Many fields required in AutoReg forms are common profile fields that the SDK may already have asked the user. These can be prepopulated before presenting the form to the user. A call to getUserProfileMappingExpression() will return a string that contains this mapping with the profile variables surrounded by % marks. This string may contain any of the profile field constants listed in com.yodlee.core.usermanagement.UserProfile.

For example, in AutoReg form for Cox Communications (ContentServiceId 9442) the Primary Phone Number FieldInfo returns the following UserProfileMappingExpression:

"%DAYTIME_PHONE_1%-%DAYTIME_PHONE_2%-%DAYTIME_PHONE_3%"

If the application generating the form for the user has access to the user's phone number, it could prepopulate this field.

8.3.5 Retry Form After a User Error

When a user is unsuccessful filling out the values for a form, the refresh of the item will return an error code. For add item and auto-registration the form metadata may be retrieved with the item number to have it populated with the users previously entered values as well as any field-level error messages encountered by the agent.

8-21Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 73: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Account Management for MFA Items

8-22

8.3.5.1 FieldInfo Value

If there is an error when attempting to add an item or run auto registration for an item, the SDK provides a method to get back the form metadata with the user's previous entries as well as any error messages for each entry that was returned for the end user site.

The current stored values of each FieldInfo may not be directly accessed. Only the HTML-escaped versions may be access using the helper class EscapedFieldInfoHelper. This ensures that any previously entered user value will not cause errors within an HTML page and also removes the vulnerability of a cross-site scripting attack.

8.3.5.2 AutoReg Field Level Error Messages

For AutoReg fields additional methods are supplied to get back error messages obtained by the agents when failing to register the user:

AutoRegFieldInfoSingle .getFieldErrorCode

AutoRegFieldInfoSingle.getFieldErrorMessage

If a field error code is present, the user should be informed that this is one of the fields that caused auto-registration to fail. Additionally the field error message should be displayed to the user to help him correct the mistake.

8.4 Account Management for MFA Items

8.4.1 MfaQuestionAnswer

The MfaQuestionAnswer class represents the MFA security question and answers. The instance of this class is used for getting and setting the MFA question and answers from and to the database. The signature of this class is -

public class MfaQuestionAnswer {

private long

mfaQuestionAnswerId;

private String mfaQuestion;

private String mfaAnswer;

}

where the mfaQuestionAnswerId is the id of this record in the database, mfaQuestion is the question string and mfaAnswer is the answer string.

Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 74: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

MFA Refresh

8.5 MFA Refresh

8.5.1 MFARefreshInfo

The MFARefreshInfo object contains information that will be sent by the gatherer as the intermediate response. This information will indicate what is needed from the user to complete the refresh. The signature of this class is -

public class MFARefreshInfo {

boolean

isMessgeFetched;

MFAFieldInfo fieldInfo;

Long timeOutTime;

}

where the field will contain details about the MFA type Login field . This enables the application to display the fields. The timeout interval can be useful in checking the user's response. In case of a delayed response, this refresh should be stopped by calling the Refresh.stopRefresh API after the timeout interval is complete.

8.5.2 MFAFieldInfo

This is an abstract class that will have all information like login field type, question and answers or image or tokenId details based on the MFAType, etc. The security question or image can be shown to the user by using this object only.

The signature of the class can be -

public abstract class MFAFieldInfo {

protected abstract String getMFAType();

}

8.5.2.1 ImageFieldInfo

This class will have the login field type of the image and the image shown at the site. The signature of the class can be -

public class ImageFieldInfo extends MFAFieldInfo implements Serializable {

private String responseFieldType;

8-23Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 75: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

MFA Refresh

8-24

private String imageFieldType;

private byte[] image;

private int minimumLength ;

private int maximumLength ;

private String displayString;

}

displayString is a string that has to be shown to the user when the user is asked to enter the image.

The minimumLength and the maximumLength are the values set by the agent. After getting the image response from the user, the application should validate whether the length of the response is between these values or not. If it is not, application should throw appropriate exception.

8.5.2.2 TokenIdFieldInfo

The signature of the class can be -

public class TokenIdFieldInfo extends MFAFieldInfo implements Serializable {

private String responseFieldType;

private int minimumLength ;

private int maximumLength ;

private String displayString;

}

The displayString is a string that has to be shown to the user when asking the user to enter the image.

The minimumLength and the maximumLength are the values set by the agent. After getting the image response from the user, the application should validate whether the length of the response is between these values or not. If it is not, the application should throw the appropriate exception.

8.5.2.3 SecurityQuestionFieldInfo

The SecurityQuestionFieldInfo class will have the login field type of questions and an array of QuestionAndAnswerValues objects. This array can have more than one object

Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 76: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

MFA Refresh

when more than one security questions is asked at the site. The signature of this class will be -

public class SecurityQuestionFieldInfo extends MFAFieldInfo implements Serializable {

private QuestionAndAnswerValues[] questionAndAnswerValues;

private int numOfMandatoryQuestions;

}

The numOfMandatoryQuestions is an integer value that will tell the user how many questions the user has to answer. If the number of answers given by the user is less than this, the application should throw an appropriate exception.

This object questionAndAnswerValues can be an instance of any one of the following class.

SingleQuesSingleAnswerValues

SingleQuesMultiAnswerOptionsValues

MultiQuesSingleAnswerValues

MultiQuesMultiAnswerOptionsValues

The casting can be done based on the responseFieldType and questionFieldType of the QuestionAndAnswerValues class.

Question - label, Response - text -----> SingleQuesSingleAnswerValues

Question - label, Response - radio -----> SingleQuesMultiAnswerOptionsValues

Question - label, Response - dropDown -----> SingleQuesMultiAnswerOptionsValues

Question - radio, Response - text -----> MultiQuesSingleAnswerValues

Question - dropDown, Response - text -----> MultiQuesSingleAnswerValues

Question - dropdown, Response - dropdown -----> MultiQuesMultiAnswerOptionsValues

Question - dropdown, Response - radio-----> MultiQuesMultiAnswerOptionsValues

Question - radio, Response - dropdown-----> MultiQuesMultiAnswerOptionsValues

Question - radio, Response - radio-----> MultiQuesMultiAnswerOptionsValues

8.5.3 QuestionAndAnswerValues

QuestionAndAnswerValues is an abstract class and will contain the sequence number and the metaData of the question. The signature of this class can be -

8-25Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 77: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

MFA Refresh

8-26

public abstract class QuestionAndAnswerValues implements Serializable {

private String questionFieldType;

private String responseFieldType;

private String isRequired;

private int sequence;

private String metaData;

}

isRequired will tell that this question is a must or not. It can have one of the two values 'Yes' or 'No'.

The metadata field added in the question node is a garbage-in garbage-out field as far as the platform and application are concerned. This field can be used by agent developers as and when there is a need to tie some information with respect to the logic at the site and how it needs to manage the responses to the MFA requests.

Normally the security questions that can be asked in the site at the time of login can be of various types. The possible types are given below.

1. There can be only one question and the user can be asked to enter his or her answer for that question. So the login field type of the question and answer can be

Question - label.

Answer -- text

2. There can be one question and multiple answer options and the user can be asked to select one of those answers. So the login field type of the question and answer can be

Question - label.

Answer -- radio / dropdown.

3. There can be multiple questions and the user can be asked to select one of those questions and enter the answer for that question. So the login field type of the question and answer can be

Question - radio / dropDown.

Answer -- text.

4. There can be multiple questions and multiple answers for each question. Based on which question the user selects, the appropriate answer options will be shown to the user and the user can be asked to select one of the answers for that question. So the login field type of the question and answer can be

Question - radio / dropDown.

Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 78: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

MFA Refresh

Answer -- radio / dropDown.

These four cases are captured in three different classes given below, which are all extends the QuestionAndAnswerValues class.

8.5.3.1 SingleQuesSingleAnswerValues

The SingleQuesSingleAnswerValues class will have the single question asked in the site. The signature of this class can be -

public class SingleQuesSingleAnswerValues extends QuestionAndAnswerValues{

private String question;

}

8.5.3.2 SingleQuesMultiAnswerOptionsValues

The SingleQuesMultiAnswerOptionsValues class will have the single question and all the answer options given in the site for that question. The signature of this class can be -

public class SingleQuesMultiAnswerOptionsValues extends QuestionAndAnswerValues{

private String question;

private String[] answerOptions;

}

8.5.3.3 MultiQuesOptionsSingleAnswerValues

The MultiQuesOptionsSingleAnswerValues class will have all the questions asked in the site as an option to the user to select. The signature of the class can be -

public class MultiQuesOptionsSingleAnswerValues extends QuestionAndAnswerValues{

private String[] question;

}

8.5.3.4 MultiQuesMultiAnswerOptionsValues

The MultiQuesMultiAnswerOptionsValues class will have a string array of all the questions and the mapping between each question and multiple answers. Depending on which question the user selects, the answer options can be taken from the hash map. The signature of this class can be -

public class MultiQuesMultiAnswerOptionsValues extends QuestionAndAnswerValues{

8-27Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 79: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

MFA Refresh

8-28

private String[] questions;

private HashMap <String, String[]> questionAnswersMapping;

}

8.5.4 MFAUserResponse

The MFAUserResponse class will modal the user response. This will be an empty call and will be derived by the classes that will modal the response of the various MFA type.

public class MFAUserResponse {

getMFAType();

}

8.5.5 MFATokenResponse

The MFATokenResponse class will modal the user response for the token type MFA. This signature of this class can be -

public MFATokenResponse extends MFAUserResponse {

private String token;

getMFAType();

}

where the token will be the token that is entered by the user.

8.5.6 MFAQuesAnsResponse

The MFAQuesAnsResponse class will model the user response for the question answer type MFA. The signature of this class can be -

public class MFAQuesAnsResponse extends MFAUserResponse {

QuesAndAnswerDetails[] quesAnsDetailArray;

getMFAType();

}

where the quesAnsDetailArray will have a array of QuesAndAnswerDetails objects, which will have all the details like question, answer, questionType, answerType and metaData.

Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 80: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

MFA Refresh

8.5.7 MFAImageResponse

The MFAImageResponse class will model the user response for the image type MFA. The signature of this class can be -

public class MFAImageResponse extends MFAUserResponse{

String imageString;

getMFAType();

}

where the image string the string that is entered by the user.

8.5.8 QuesAndAnswerDetails

The QuesAndAnswerDetails class will have all the details like the question and answer that the user selects, the login field type of question and answer, and the metadata associated with that question. The signature of this class can be -

public class QuesAndAnswerDetails implements Serializable {

private String question;

private String answer;

private String questionFieldType;

private String answerFieldType;

private String metaData;

}

8.5.9 Retrieve MFA Question Answers

The retrieve MFA question answers API is used to retrieve the MFA questions and answers related to the item which are either learnt or migrated from the previous versions. A new SDK object has been created to represent the MFA question answer object present in the system.

8.5.10 MfaQuestionAnswer

The MfaQuestionAnswer API will check whether the item is related to an MFA site. If so, check whether the cobrand supports MFA. Only when both the above conditions are satisfied it returns the related MFA question answer array or it will throw an exception.

Please refer to Javadocs for more details on this specific API.

8-29Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 81: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Historical Account Data

8-30

8.5.11 Update MFA Answers

The Update MFA Answers API is used to update the answers for the MFA item. This API checks whether the item belongs to a MFA related site and cobrand supports MFA. Then update the answers based on the input provided.

Please refer to Javadocs for more details on this specific API.

8.6 Historical Account Data

The Yodlee platform supports the ability to store account level historical data. This functionality is useful for developing historical charting applications to show such things as net worth and asset allocation trends over time. Historical information is supported for the following containers.

Bank

Credit Card

Investment

Bill

Loan

8.6.1 Configuration

Historical account settings can be configured per container / per cobrand basis using the following parameters.

Start Time - determines the time historical information is first generated. Options include: Immediately (default), Next Monday, Next Tuesday, Next Wednesday, Next Thursday, Next Friday, Next Saturday, Next Sunday, 15th of This Month, Last Business Day of This Month, First Business Day of Next Month, 15th of Next Month.

Dataset Frequency - determines the frequency with which the offline historical data generation process runs. Options include: 1d, 2d, 3d, 5d, 7d (default), 10d, 15d, 30d.

History MinLength - determines the minimum time in days account history is stored.

Dataset Minimum Granularity - determines the minimum time between successive entries in the account history table (represented in seconds).

If account history is supported for a customer, these settings should be configured at the time of deployment. Customers should contact their project managers for additional information or to establish their preferred settings.

8.6.2 Operation and Implementation

The Yodlee platform always stores the most recently aggregated data in the OLTP. When data is refreshed, either via an on-demand application request or as a result of a

Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 82: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Historical Account Data

scheduled offline process called a cache run, the existing data in the OLTP is replaced with the newer data. In the process of updating the data, the LastUpdatedTime field in the account table is updated with the time of the data refresh. In this way, only one dataset per member item is ever stored at any given time and it is always the most recent. This also implies that during typical operation of the system, no historical data is stored.

To generate account history for the containers and data supported by the historical data APIs, an offline process called YTask is employed. Following the configurable parameters described above, YTask periodically copies the most recent data from the account table and inserts it into the account history table for the appropriate container.

While this concept is simple enough, a few more details explaining the logic employed by YTask are required to gain a full understanding for how to implement a charting application.

8.6.3 History Creation

YTask compares the LastUpdatedTime in the account table to the time history was last added to the account history table. If the difference between these values is greater than the dataset minimum granularity, the data in the account table is copied to a new row in the account history table. If the difference is less than the dataset minimum granularity, YTask does not update the account history table and the process is rescheduled according to the dataset frequency parameter. This effectively limits the account history table to, at most, one dataset per dataset minimum granularity interval.

8.6.4 Dataset Interpolation

Since the creation of history is tied to the LastUpdatedTime, it is highly dependent on data being refreshed on a regular basis. Typically, for active users within the system, this is satisfied by either on-demand refreshes or offline refreshes initiated as part of the cache run scheduled by the Yodlee platform. It cannot be assumed, however, that every account for every user will always be refreshed with a frequency necessary to produce a perfect account history. If a user becomes inactive, there are refresh errors, or the cache run rules dictate a refresh frequency greater than the dataset minimum granularity, it is possible that there will be missing dataset(s) in the account history table. Consequently, the application must be able to effectively interpolate the missing datasets and fill in the details to produce a complete graph.

8.6.5 Account Data Included

The historical data APIs return all of the data contained within the account history table in addition to the current data in the account table. It is up to the application to determine whether to include the dataset from the account table as part of the overall history. It should also be noted that this dataset might be a duplicate of the last dataset added to the account history table. This depends on whether the account was refreshed since the last time YTask ran.

8-31Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 83: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

MFA Refresh

8-32

8.6.6 Custom Accounts

History is generated for custom or manual entry accounts as long as the data is stored in one of the supported containers. Application developers should also be aware that the LastUpdatedTime for custom accounts is not automatically populated by the Yodlee platform. The application needs to explicitly set the value for this field to the current time by using the ItemSummary.setLastUpdatedTime() call every time custom account information is modified. In all other respects, the history generated reflects the same rules outlined above for Yodlee refreshed accounts.

8.7 MFA Refresh

8.7.1 Get MFA Information for User Display

The Get MFA Information for User Display API polls the gatherer response queue for the response sent by the gatherer. The retrieval of the message is based on the message id included in the request itself. Therefore the gatherer puts the same message id in the response and when this API finds a message with the same message id, it updates the status of the request in OTLP database to indicate that it will get the intermediate response from the Gatherer. It also ends this to the getLoginFormFromXml* which scans the response xml and creates an object.

This object has the flag that indicates whether the message was found. The getLoginFormFromXml* converts the xml in the login form field and the values held in this field is put into this object.

If the API does not get the message then also this will return the same object but the flag is set to false, and if it does not get the message then the object will include the data and the flag will be set as true.

NOTE: The time out logic needs to be implemented in order that after a certain time, the polling of the Gatherer response queue must stop.

The API signature is -

public MFARefreshInfo getMFAResponseforSite (UserContext userContext, long memSiteAccID);

8.7.2 Send User Provided MFA Information

These APIs get the user response from the application and put this response in the application response queue*. The application sends the user response in the form of the data objects that will be SDK objects for the different MFA types. For example, for the question and answer type needed to have a MFAQuesAndResponse object, this object will have a list of the name value pair of the question and answers. These objects derive from the base object named MFAUserResponse so that this API is generic enough to take any kind of the object. Internally it checks for the kind of the object based on the MFA type.

Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 84: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

MFA Refresh

The API gets the data objects and gets the response xml by using the getResponseXmlFromVo. After getting the xml, the API puts the xml in the application response queue* the gatherer will poll for this message and when it get the message it retrieves it and sends it to the end site.

The API signature will be -

public boolean putMFARequestforSite (UserContext userContext, MFAUserResponse userResponse, long memSiteAccId);

where the MFAUserResponse if the response from the user and the item id will be used for creating the message ID and this message id will be copied to the response.

8-33Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 85: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

MFA Refresh

8-34

8.7.3 MFA Refresh Flow Diagram

Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 86: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Yodlee Hosted Wizards

NOTE: PartialComplete is a status which indicates that the account summary information is available and transactions are being retrieved from the end site.

1. Initiate refresh for this item by calling Refresh.startSiteRefresh.

2. If this sum info enable for the MFA, call the Refresh.getMfaResponseForSite to get the intermediate response.

3. The Refresh.getMfaResponseforSite API will return the MFARefreshInfo object.

4. Get the response from the user, create the MFAUserResponse object and call the Refresh.putMFARequestforSite API for sending the information to the end site. If the message is sent successfully then this API will return true.

5. Call get and put in a loop until the errorCode is null or isMessageAvailable is false.

6. Refresh service is described in Refresh.WSDL.

8.8 Yodlee Hosted Wizards

Yodlee hosted wizards are multi-step flows of hosted pages inside Yodlee that allow a consumer to perform common activities in Yodlee. By using hosted wizards, customers can avoid rebuilding user interfaces already developed by Yodlee. Yodlee hosted wizards are available in SDK and SDK Entrepreneurial Edition licenses.

Yodlee supports the following wizards:

PFM related:

Yodlee FastLink

Edit Site credentials

User Registration

Billpay related:

Add Payee

Edit Payee

Delete Payee

Add Payment Account

Delete Payment account

Setup ebill

Edit ebill

Delete ebill

Hosted wizard URLs use OAuth for authorizing the application. The URL is signed with OAuth access token in order to protect the URL. OAuth parameters consumer key, consumer token, callback URL, version, nonce, timestamp, oauth signature are mandatory.

8-35Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 87: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Yodlee Hosted Wizards

8-36

The access token required to sign the URL can be obtained by invoking the following API where bridgetAppId is the unique identifier of the FinApp published for the customer environment for the purpose of launching hosted wizards.

public OAuthAccessToken getOAuthAccessToken(UserContext userContext, Long bridgetAppId)throws

InvalidUserContextException,

InvalidApplicationIdentifierException,

IllegalArgumentValueException,

InvalidBridgetStatusException

After exiting a Hosted Wizard, Yodlee recommends that the access token be invalidated to prevent its misuse via a security attack. The following API invalidates an active access token.

public Boolean invalidateOAuthAccessToken(UserContext userContext, Long bridgetAppId, String token)

throws

InvalidUserContextException,

InvalidApplicationIdentifierException,

IllegalArgumentValueException,

InvalidAccessTokenException;

8.8.1 Yodlee Hosted Wizard Example: Yodlee FastLink

Yodlee FastLink has a multiple step flow that allows a consumer to link a held away account in Yodlee PersonalFinance. The hosted wizard may be launched using the following deep link URL:

https:/moneycenter.yodlee.com/moneycenter/addAccounts.yodlee.action

Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 88: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Yodlee Hosted Wizards

In addition to the basic deep link URL, the Yodlee FastLink supports the passing of additional launching parameters as URL parameters.

The following image shows Yodlee FastLink as it appears on desktop displays.

Fig. 8-10: Yodlee FastLink – Desktop

Table 8-1: Yodlee FastLink - Launch Parameters

Launch Parameter

Description

displayMode The display mode will affect the default display of the wizard and may be used for premium cobranding with professional services. The display mode can have one of the following as the parameter value:• Desktop – (default) uses the standard application stylesheet• Mobile – presents a customized format for touch browsers in a smaller screen size

such as iPhone, iPad, Galaxy, Droid, etc.

oauth_callback At the end of Yodlee FastLink flow the wizard will redirect the browser to the location provided in the URL as a standard browser redirect. Generally this will look similar to https://www.iqbank.com/home. There is one special case of “oob” which means this request is considered “out of bounds” from a normal web request. At the end of the wizard a confirmation screen is shown, but there is no final redirect.

8-37Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 89: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Yodlee Hosted Wizards

8-38

The following image shows Yodlee FastLink as it appears on mobile devices.

Fig. 8-11: Yodlee FastLink – Mobile

Chapter 8: Implementation of SDK Functions

Yodlee, Inc. © Copyright 2013 Confidential

Page 90: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Chapter 9: Upgrade Policy

9.1 Support for WSDL in Version 12.0

Yodlee supports APIs for 24 months or until 2 releases prior to current release. Yodlee SDK supports APIs introduced in 9.0.4 or later.

If a customer is upgrading and wishes to use the doc-literal Encoding style WSDL files and customer APIs have not been changed, the customer can upgrade following the steps that follow:

1. Yodlee provides a SDK server - The customerwill need to contact its Yodlee representative / Professional Services team for the v12.0 SDK server.

2. Download the WSDL files from the SDK Server and generate the client side libraries in the customer’s framework of choice.

3. Recompile the code against the newly generated client-side libraries. The client code should compile without errors.

4. If the customer wants to use new features in the 12.0 SDK, the customer should follow this guide. The Yodlee Professional Services team offers technical consulting services for using the SDK. Please contact the appropriate Yodlee Sales Representative or the Professional Services team for more information.

5. If a customer is on Yodlee 5x, 6x, 7x or 8x SDK, it is possible that Yodlee no longer supports one or more APIs. In that event, Yodlee will provide alternate APIs that will support the desired functionality.

NOTE: From 10x onwards, Yodlee does not generate client libraries and only provides WSDL files to its customers.

Chapter 9: Upgrade Policy

Yodlee, Inc. © Copyright 2013 Confidential

9-1

Page 91: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Chapter 10: Common Issues

10.1 Invalid Certificate

The Yodlee staging environment typically has an invalid certificate associated with it. The client must be configured to allow connection to this type of certificate. The solution will differ, based on the client libraries used.

Axis 2 1.x (and Yodlee Java Client Libraries)

To install a temporary server certificate, complete the following steps:

1. Download the Not Yet Common ssl package (not-yet-commons-ssl-0.3.11.jar): http://juliusdavies.ca/commons-ssl/download.html

2. Add the following lines of code to the startup method:

Protocol.unregisterProtocol("https");

Protocol.registerProtocol("https",

new Protocol("https", new org.apache.commons.httpclient.contrib.ssl.EasySSLProtocolSocketFactory(), 443));

Axis 1.x

To install a temporary server certificate, complete the following steps:

1. Go to SOAP server URL. Ex: https://localhost:9080/yodsoap/services

2. In the Security Alert window, click View Certificate. If the Security Alert does not appear, double-click the padlock icon at the bottom of the browser.

3. Click the Details tab and choose Copy to File. The Certificate Export Wizard is displayed.

4. Click Next.

5. Choose the export file format as "Base 64-encoded X.509 (.CER)" and click Next.

6. Specify the name of the export file and click Next.

7. Click Finish. The following message is displayed: "The export was successful."

8. Click OK to close this message.

9. Click OK to close the certificate window.

To import and trust your certificate, complete the following steps:

1. At the command prompt, use the following syntax to import the certificate to your keystore:

% keytool -import -file <Yodlee certificate file path>

[-alias <alias name for certificate>]

[-keystore <keystore file path>]

Chapter 10: Common Issues

Yodlee, Inc. © Copyright 2013 Confidential

10-1

Page 92: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Logging SOAP Messages

10-2

[-storepass <password>]

Use the following default JDK keystore path:

<Java home>\java\jre\lib\security\cacerts

The default password for keystore is "changeit". For example:

% keytool -import -file C:\partner.cer -alias mypartner

-keystore C:\java\jre\lib\security\cacerts -storepass changeit

If you receive an error, try double quotes around both file paths. For example:

% keytool -import -file "C:\partner.cer" -alias mypartner

-keystore "C:\java\jre\lib\security\cacerts" -storepass changeit

2. When you receive the following prompt, enter Y and hit Return to trust the certificate:

% Trust this certificate [n]

3. To verify that the import was successful, use the following command to list the certificates in the keystore:

% keytool -list -keystore C:\java\jre\lib\security\cacerts

-storepass changeit

10.2 Logging SOAP Messages

When sending issues to Yodlee Professional Services or Yodlee Customer Care, the most important information to send is the SOAP message being passed. Therefore, early on, it's good to learn how to log the SOAP message.

Axis 2 1.x (and Yodlee Java Client Libraries)

Since Axis 2 uses HttpClient for interaction, increasing logging levels of the client will print the soap messages. This can either be done by update your log4j configuration file directly, or by setting the following command line options:

-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog

-Dorg.apache.commons.logging.simplelog.showdatetime=true

-Dorg.apache.commons.logging.simplelog.log.httpclient.wire=debug

-Dorg.apache.commons.logging.simplelog.log.org.apache.commons.httpclient=debug

Chapter 10: Common Issues

Yodlee, Inc. © Copyright 2013 Confidential

Page 93: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Logging SOAP Messages

Axis 1.4 (Yodlee SOAP Sample Apps)

For Apache Axis 1.4, logging can be handled by putting a logging handler into the client deploy configuration and adding it to the request and response flow. A simple way to do this is create the following file in your runtime path:

client_deploy.wsdd:

<?xml version="1.0" encoding="UTF-8"?>

<deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">

<handler name="log" type="java:org.apache.axis.handlers.LogHandler">

<parameter name="LogHandler.fileName" value="axis.log" />

</handler>

<globalConfiguration>

<requestFlow >

<handler type="log" />

</requestFlow>

<responseFlow>

<handler type="log" />

</responseFlow>

</globalConfiguration>

<transport name="http" pivot="java:org.apache.axis.transport.http.HTTPSender" />

<transport name="https" pivot="java:org.apache.axis.transport.http.HTTPSender" />

<transport name="local" pivot="java:org.apache.axis.transport.local.LocalSender" />

</deployment>

Then pass the following parameter to the runtime to point to this new file:

-Daxis.ClientConfigFile=client_deploy.wsdd

10-3Chapter 10: Common Issues

Yodlee, Inc. © Copyright 2013 Confidential

Page 94: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Chapter 11: Reporting Issues

11.1 How To Report Issues

For reporting a problems not answered by the FAQ section, please contact the appropriate Yodlee Project Manager or support resource with information available from stdout or stderr log files.

If possible, include either sample code that simulates the problem or the SOAP request/response message body (obtained from the TCPMonitor tool or any other tool that can show the SOAP message body in the http traffic)

Chapter 11: Reporting Issues

Yodlee, Inc. © Copyright 2013 Confidential

11-1

Page 95: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Appendix A: Terminology

A.1 Introduction

This appendix provides detailed definitions for terms that are helpful for Yodlee SDK developers to know to leverage the Yodlee SDK to build custom applications.

A.2 Terms

Automated Intelligent Refresh (AIR)

Automated Intelligent refresh is a set of rules-based logic that optimizes the offline refresh frequency of aggregated data stored in the Yodlee Data Repository. For example, users who have not logged into the system in n days may not have their data updated until they log in and re-establish themselves as an active user.

Aggregated Data

Data collected by Yodlee Platform on behalf of members.

Asset Type

An attribute associated with a container that determines whether it's an asset, a liability, or neither.

Cobrand

A cobrand is a namespace exclusively associated with one customer. It may contain a set of unique members and is associated with one or more applications.

Cleansing Augmentation Normalization (CAN)

Technology that improves the quality and consistency of aggregated data through a process of cleansing, augmentation, and normalization.

Configuration Database

The configuration database is the database used to store the operational and configuration parameters. These parameters are used during the start-up and run-time execution of all Yodlee Platform components.

Container

A container defines a particular type of aggregated data. Example:

Banking

Credit Card

Containers may contain child containers or sub-containers that further define a particular type of aggregated data. Example

Holdings

Transactions

Statements

Chapter A: Terminology

Yodlee, Inc. © Copyright 2013 Confidential

A-1

Page 96: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Terms

A-2

Content Service

A content service represents a relationship between a container and a specific site. Each content service corresponds to exactly one site. Multiple content services may exist for a given site. An exception is a custom service with data manually entered by a user. These are also considered content services even though they do not have a 1:1 relationship with a site. Examples:

Citibank Banking (Site = Citibank, Container = Banking)

Citibank Credit Card (Site = Citibank, Container = Credit Card)

Credentials

Credentials represent any permutation of usernames, passwords, and other information required to authenticate a user.

Data Service Types

A data service type is a logical real world grouping of data related to an item account. It is always associated with a container. Each container can contain multiple data service types.

Examples:

Banking (describes the data related to the Container "Banking")

Investment (describes the data related to the Container "Investment")

Holding (describes the data related to holdings in the Container "Investment)

Transaction (describes the data related to transactions in the Container "Investment)

Statement (describes the data related to statements in the Container "Investment)

Gatherer

The gatherer is the component in the Yodlee Data Engine that collects data from Yodlee-supported sites.

Member Item (Item)

An Item is an instance of a Content Service that corresponds to actual data collected on behalf of a Member. Every Item has a unique identifier and has a 1:1 correspondence with a Container. An Item consists of one or more Item Accounts.

Internal Warnings

Internal Warnings is an internal data quality tool that allows Yodlee to proactively monitor every data element gathered for consistency and accuracy. The tool is based upon monitoring events that alert the system administrator to possible anomalies in the data gathered. Based on these alerts, gathering scripts are modified or new algorithms are added to the CAN infrastructure to ensure the highest quality of data is available to all applications.

Chapter A: Terminology

Yodlee, Inc. © Copyright 2013 Confidential

Page 97: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Terms

Item Account

An Item Account is contained within an Item and represents a logical set of collected data that corresponds to a "real world" account. Item Accounts correspond to actual account entities as users generally think of them. Example:

Joe's Citibank Checking 1 (associated with Joe's Citibank Online Bank Item)

Joe's Citibank Checking 2 (associated with Joe's Citibank Online Bank Item)

Joe's Citibank Credit Card (associated with Joe's Citibank Online Credit Card Item)

Member

A Member represents a unique user within a Cobrand. A Member is created when a user registers for a Yodlee application or service, either explicitly via the registration process or implicitly via Single Sign On. Once created within a cobrand, the Member ID cannot be changed.

MQ server

The MQ server handles all message requests within the Yodlee Data Engine and routes them to the appropriate module based on priority and other intelligent message handling rules.

Organization

A logical entity that typically corresponds to an organization in the real world and consists of Sites from which data may be collected. Examples:

Citibank (Organization)

Citibank Bank (Site)

Citibank Credit Card (Site)

Merrill Lynch (Organization)

Partial Account

A Partial Account is a Site Account that has incomplete or missing credentials. Data is not collected for Partial Accounts. Accounts may be considered "Partial" if the set of Credentials is incomplete even though a subset is available and sufficient to allow successful authentication. The notion of Partial Account does not presuppose that any credentials entered by the user are correct.

Refresh

A Refresh is the act of updating Aggregated Data for one or a set of Item Accounts to obtain the most recent data available. Refresh requests may originate from either an explicit request during a user session (for user or application-initiated refreshes) or the Refresh Scheduler (for offline, automated refreshes)

A-3Chapter A: Terminology

Yodlee, Inc. © Copyright 2013 Confidential

Page 98: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Terms

A-4

Refresh Scheduler

The Refresh Scheduler is a module within the Yodlee Refresh Server. Using AIR logic, the Refresh Scheduler analyzes a set of variables for each Item Account and generates refresh requests on behalf of users not currently logged in and/or requesting data. This serves to improve the relevancy of the data most likely to be accessed by users while minimizing offline data collection waste.

Refresh Server

The Refresh Server contains the Yodlee CAN Server and the Refresh Scheduler, which file updated Aggregated Data into the Yodlee Data Repository, and manages the creation and queuing of Refresh requests.

Refresh Servlet Server

The Refresh Servlet Server contains the Request Servlet and Response Servlet. The Request Servlet receives Refresh requests from the Request Queue in the MQ server and passes them to the Gatherer. The Response Servlet receives Refresh responses from the Gatherer and passes them to the Response Queue in the MQ server.

Site

A Site is the set of Content Services that can be accessed with the same credentials. An Organization may have multiple Sites. For a given Organization, the set of Content Services that do not require credentials are also considered a Site.

An example Site named "Citibank Bank" may include the following Content Services:

Citibank Checking

Citibank Savings

A different Site within the same Organization named "Citibank Investment" may include the following Content Services:

Citibank Brokerage

Citibank Bonds

Site Account (Mem Site Account)

A site account associates the user to a site, where a set of credentials required to access all the accounts available in the site. The site may have different types of accounts like banking, cards, loans, etc available in the site. For example, BankIQ has cards, loan and banking accounts provided in the same site and only a single set of credentials used to access all these account types.

Source Element ID

The Source Element ID is a unique identifier of a transaction generated by the Yodlee Platform. This identifier is derived from a combination of multiple fields within a transaction instance.

Chapter A: Terminology

Yodlee, Inc. © Copyright 2013 Confidential

Page 99: Yodlee SDK Developers Guide v12.0 SDK Developers Guide...Yodlee SAML Implementation Guide - This document describes how customers can configure and implement a SAML SSO solution with

Terms

Yodlee Account

The Member account created within the Yodlee Platform is referred to as a Yodlee Account. Before creation, a user must accept the terms and conditions of use. If the user has accepted the relevant T&C, the account is considered active. If the T&C is updated and the user has not yet accepted them, it is considered inactive until acceptance is obtained.

Yodlee Data Agent (Agent)

A Yodlee Data Agent is a software component within the Gatherer that collects data from one or several Content Services. The method of collection may be via any number of standards-based or proprietary direct data feeds such as HTML, OFX, IFX, XML, and YML. Yodlee Data Agents may be initiated on demand by applications or by the Refresh Scheduler.

Yodlee CAN Server

The Yodlee CAN Server is responsible for filing Aggregated Data into the normalized data schema of the Yodlee Data Repository.

Yodlee Data Engine

The Yodlee Data Engine is the set of infrastructure components that intelligently aggregates, cleanses, augments and stores data on behalf of Members with their permission and using their credentials. The Yodlee Data Engine is capable of aggregating a highly extensible range of data from a large number of Data Providers using a variety of structured and semi-structured data formats.

Yodlee OLTP (Online Transaction Processing) Database

The Yodlee OLTP Database is the collection of all Aggregated Data in Yodlee Platform as well as all other persistent data including:

Source Data - this is data relating to the Sites for the different content services such as URLs, site display names for HTML scraping feeds, auto-login URL and credential information for authentication with the content source.

Cobrand Data - includes the customizations that are specific to the installation of Yodlee Platform.

Member Profile Data - includes the profile information and the authentication credential information for Members of Yodlee Platform.

Item Information - includes the Items that have been added to Yodlee Platform by Members and the credentials associated with each of them.

Ytask

Ytask modules perform scheduled and asynchronous activities such as operational maintenance and user notification.

A-5Chapter A: Terminology

Yodlee, Inc. © Copyright 2013 Confidential