Cobrand

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

Cobrand Login

A process by which a developer  authenticates their application with the Yodlee API before registering its user and performing other actions like adding accounts, getting transactions, etc., on behalf of its user. You will receive cobrand credentials and an Application ID to authenticate with the Yodlee API.

Content Service 

(e.g., a site like Bank of America Online Banking)

Yodlee stores information for all the institutions it supports inside the Yodlee database. These institutions are referred to as content services and contain metadata such as login form information and support for different Yodlee features sets (e.g., Personal Financial Management, Direct Pay, Instant Account Verification, etc.). Each content service corresponds to exactly one site. Multiple content services can exist for a given site. An exception is a custom service with data manually entered by a user.

Examples:

  • Yahoo Email (Site = Yahoo, Container = Email)
  • Yahoo Calendar (Site = Yahoo, Container = Calendar)
  • Citibank Banking (Site = Citibank, Container = Banking)
  • Citibank Credit Card (Site = Citibank, Container = Credit Card)

Whenever a user is adding an account to the Yodlee system, the login form metadata for the content service must be used to render the form to the user. It is possible to make a real-time call to retrieve that login information each time it is required, but since login form information does not change frequently, it is often better to store that information in a local cache. A daily synchronization of information usually offers the best performance versus stale data caching methodology.

DB Filer

A Yodlee Data Engine component designed to receive the results of a data request and file the new data in the OLTP database.

Gatherer

A data agent that picks up refresh requests and gathers account information from financial sites.

Item

An item is an instance of a content service that corresponds to actual data collected on behalf of a user (i.e., member). Each Item has a unique identifier and a 1:1 correspondence with a container. An item consists of one or more item accounts.

Item Account

Contained within an item a container account 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.

Examples:

  • Joe's Citibank Checking (associated with Joe's Citibank Online Bank Item)
  • Joe's Citibank Savings (associated with Joe's Citibank Online Bank Item)
  • Joe's Citibank Credit Card (associated with Joe's Citibank Online Credit Card Item)

Item Account Concepts

If a user has 5 different accounts across different types (containers in Yodlee parlance) like Bank Of America bank account, Citibank credit card account, Comcast cable, AT&T wireless & PG&E utilities, these are called items.

Within an item, say Citibank credit card account, if the user has 2 different credit cards – 1 is rewards and another is privilege card, Yodlee gathers both of them during refresh process and stores each as an item account. The relationship between an item to an item account is one too many. One item can have more than one item account associated with it.

Login

See Registration.

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; however, it can be unregistered from the Yodlee system.

Member Item

A financial institution added by a consumer.

Multifactor Authentication (MFA)

MFA verifies the identity of customers of a financial institution through a series of steps when they log in to their accounts online. While the first step is the simple entry of user name and password, the additional steps can involve answering some security questions or providing some dynamic information. Yodlee supports sites that have different kinds of MFAs implemented.  Users with MFA accounts can aggregate within Yodlee system.

MFA Examples:

  • Security Question & Answer
  • Token Id
  • Image Recognition (CAPTCHA-Completely Automated Public Turing test to tell Computers and Humans apart)

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)

Refresh an Item

Refresh is performed on an item or group of items belonging to a user. Initiating a refresh on an item will cause several Yodlee back end components to interact with each other in obtaining the latest information about the item from the site where the corresponding account or set of accounts (item accounts) of an item belongs.

Registration

Users (i.e., members) must be registered before they can perform additional functions like adding accounts, viewing details, etc. Once registered, users must log into the Yodlee system to perform similar operations. Note that CobrandContext is passed when users are registered and logged in. The registration and login processes establish a user session with Yodlee and return the userContext data type. 

Site Account

In Yodlee terms, site account is the association of a consumer with accounts available in the site.

Transactions & Categorization

Transactions belonging to different accounts like bank, card, investments etc., are automatically categorized by Yodlee when they are extracted the first time from the end site. They are mapped to a predefined set of categories. SDK allows change to particular transaction category. Sub-categories within a parent category can be created using SDK and transactions can be associated to it.

UserContext

The userContext data type encapsulates information about a user (i.e., member). When deploying in SOAP mode, the context is required for attempting a user login. Usercontext is essential when performing any operation on behalf of the user, including adding an account, refreshing, getting transaction information, performing categorization, etc.