March 31, 2020

March Release Notes 2020

Envestnet | Yodlee

Yodlee APIs – New Features/Enhancements

Credential-based Token Generation for Authentication

In response to customer feedback, Yodlee is introducing a new and simplified authentication mechanism. Based on the OAuth 2.0 framework, this simpler approach removes the need for handling cryptographic keys.  Access tokens are created by presenting credentials issued on the client’s behalf. 

URL: POST  /auth/token

Note: As unique configurations are required to upgrade, existing customers who wish to switch to the client credential authentication should contact Yodlee Client Services.

Implicit User Registration Using Credential-based Token Authentication Flow

With the new credential-based token authentication flow, the POST /auth/token API can not only authenticate but also performs an implicit user registration. Rather than using a separate call, the API automatically registers new users when generating a related token for the first time. The user’s details can be updated using the PUT /user API.

URL: POST  /auth/token

Note: As unique configurations are required to upgrade, existing customers who wish to switch to the client credential authentication should contact Yodlee Client Services.

User Registration - Removed Email-ID Validation

To streamline the registration process, Yodlee has upgraded the user-registration service to work without an email-ID.

URL: POST  /user/register

New Entity - Configs

Yodlee is introducing a new configs entity. Using the APIs in the configs entity developers can subscribe to webhook notification and get public encryption key.

  • Webhooks notification APIs: Developers can get their consumers' data in an efficient and secure way by subscribing to the webhook notifications. These APIs provide incremental payload data that is inserted, updated, or deleted in the system for a defined duration.

    POST  /configs/notifications/events/{eventName}


    GET   /configs/notifications/events


    PUT  /configs/notifications/events/{eventName}


    DELETE  /configs/notifications/events/{eventName}

  • Public encryption key API: A unique public encryption key is issued to developers using the Yodlee aggregation services. Using this service developers can get encryption keys to encrypt their client credentials.

    GET   /configs/publicKey

Note: The cobrand entity that also provides similar features will soon be deprecated in the upcoming Yodlee API versions.

Smartzip – Real Estate Support

Yodlee is introducing real estate aggregation support through Yodlee API v1.1. Users can aggregate their property and the valuation of that property will be fetched through the Smartzip integration. Property valuations will be automatically updated every 7 days. Operations that will be allowed for real estate aggregation follow:

  • Adding the property
  • Editing the property address
  • Deleting the property

Institutions Entity Enhancement

For Open Banking, the GET /institutions API has been enhanced to return all institutions when the API is called without any filters. The default priority parameter value is set as ALL.

The priority parameter currently only accepts the value SEARCH and the name parameter is mandatory for the GET /institutions.

New Field in GET Transactions API

A new field sourceId is introduced in the GET /transactions API response. The sourceId field is a unique ID that the financial institution (FI) or a provider assigns to the transaction.

The sourceId field is only available for the pre-populated accounts. Pre-populated accounts are the accounts that the FI shares with Yodlee, as opposed to the ones added by the user.

Important Notes and Bug Fixes

  • The provider account APIs in v1.1 have been enhanced to return additional status for all the provider account statuses. The additional status LOGIN_IN_PROGRESS will be returned when the provider account status is LOGIN_IN_PROGRESS or USER_INPUT_REQUIRED.
  • The PUT and POST providerAccount APIs and the update preferences API have been enhanced to validate the isAutoRefreshEnabled attribute when it is set to true for a provider account. During the add, edit, or refresh account flows, the isAutoRefreshEnabled attribute cannot be enabled if the provider account has not been requested for any of the auto-refreshable attributes.

2-legged OAuth – Gatherer, Provider, and Metadata-related Changes

Some data providers are implementing a new data connectivity method using 2-legged OAuth. Authentication through OAuth ensures that the account linking is secured using a token exchange between Yodlee and the provider. This change will not affect the end-user or the developers using the account linking feature. This change will be rolled out as providers are onboarded and customers will be appropriately notified about the changes and the timelines.

Stop Screen Scraping Solution

The stop screen scraping solution provides an ability to enable or disable screen scraping for a given set of regions, customers, or sites (and their containers) for a given period. This will help customers or sites to comply with the Open Banking (OB) standards for a given region.

The actors of the solution can effectively create stop-scraping rules for the given duration and manage these rules separately. Changes are done in the platform in the site-search behavior and refresh patterns to handle the scenario where a particular site has been disabled for screen scraping.

For the already aggregated site accounts, if the screen scraping solution has been disabled, the instant, cache, and RAL (refresh at login) account refreshes will be stopped. The account information will not be updated while the stop-scraping rules are in force.

US 3-legged OAuth

OB in the US is where the end user’s financial data aggregation is moved from credential-based screen scraping to OAuth-based API connectivity. Users can connect to sites through OB or OAuth-based API connectivity instead of credential-based screen scraping.

Better data quality, higher security, higher transparency, and end-user empowerment are some of the benefits of the OAuth-based API connectivity to sites. This change will be rolled out to select customers and they will be appropriately notified about the changes and the timelines.

Event Tracking for Amplitude

Amplitude is a dashboard analytics tool that is integrated into the Yodlee ecosystem and intends to replace Flurry.

Amplitude events for FastLink (FL) 3.0 basic aggregation, Instant Account Verification (IAV)-data service, IAV-matching service, IAV-CDV, real estate, and manual accounts have been added. These events can be used to create funnels, get event-wise segmentation, session length information, and other user demographics. Customers can visualize the actual user conversion rates using these funnels.

The tracking metric can be fetched using both Amplitude UI and via APIs through the Yodlee CustomerCare application.

Instant Account Verification for Open Banking using FastLink-Dual Site Selection

Instant Account Verification (IAV) for UK OB is supported in FL-Dual Site Selection (FL-DSS). UK OB customers who are interested in implementing the IAV feature (data service, matching service, and the optional challenge deposit verification) can request FL-DSS and start adding accounts. FL-DSS already supports OB using the relevant providers and the IAV support will complete the offering.

OBWAC and OBSEAL Certificate Onboarding Support for UK Open Banking

The OB platform is including additional support for OBWAC and OBSEAL certificates (also known as eiDAS-Lite) for customer onboarding. This essentially means, for enhanced coverage, Envestnet | Yodlee customers can now engage with Account Servicing Payment Service Provider (ASPSPs) that require the OBWAC and OBSEAL certificates for transport and signing requests, along with OB Transport and OB Signing certificates that were already supported in the past.

Transaction Data Enrichment – New Features/Enhancements

High Level Category Changes

Based on the market feedbacks, changes have been incorporated in the high level categories of Legacy Categorization (i.e., a data aggregation product feature) and the Transaction Data Enrichment (TDE) product.

The following high level category changes are only relevant to the customer who use the Legacy Categorization feature and the TDE product:

  • New additions – The two new high level categories added are:
    • Food Expenses
    • Educational
  • Renaming categories – Two high level categories renamed are:
    • Office Expenses is renamed to Business Services
    • Travel & Entertainment is renamed to Travel.
  • Mapping changes
    • Mapping of few existing categories to high level categories will change.
    • 7 of the legacy category and 5 of the merged category’s mapping to the high level category will change.

Note: There are two versions of transaction categories – legacy and merged. If you are not sure which category version you are using and for any other queries, please contact Yodlee Client Services.

Granular Categories

In addition to the master and high level categories, customers will benefit from Granular Categories. Granular categories provide the categorization at the most granular-level, helping customers get deep insights into the consumer’s income and spending behavior. Granular categories are referred as detailCategory in the GET /transactions/categories API response. For the list of granular or detail categories and their mapping to high and master level categories, refer to Transaction Category Hierarchy.

Categorization Hierarchy

The categoryLabel field in the merchant entity of the transaction API response is enhanced to have multiple values. It will provide additional categories from the Yodlee reference data (if available). This additional information is provided as a string, and is intended to provide more context to the category information. For more information, refer to Transaction Category Hierarchy.

A sample response for the category label follows:

      "Food and Dining",

Billers and Subscriptions

The billers and subscriptions feature in the TDE product allows customers to differentiate the billing and subscription transactions from other transactions. This feature will help customers provide a better insight into the upcoming bill or subscription payments. The billers and subscriptions feature is available only in the US region.

In the GET /transactions API response, billers and subscriptions are referred as merchantType. The three possible variations of the merchantType flag follow:

  • "merchantType": "BILLERS"
  • "merchantType": "SUBSCRIPTION"
  • "merchantType": "OTHERS"