The Envestnet®|Yodlee® November 2018 release includes the following major enhancements and incremental improvements:
YODLEE PLATFORM — NEW FEATURES
Additional Data for Student Loan Accounts
- Yodlee Platform now aggregates additional data on student loan accounts including payoff/payments address, outstanding balance, interest rate, borrower/cosigner name, etc.
- The additional student loan data can help customers in the student loan refinance/repayment space to simplify payments to student loan service providers on behalf of their borrowers.
- New dataset and dataset attributes have been introduced in Yodlee API v1.1. For details, refer to Envestnet | Yodlee API v1.1 Overview.
- The GET /accounts and GET /accounts/{accountId} API endpoints are enhanced to provide the additional student loan account data elements.
YODLEE PLATFORM — ENHANCEMENTS
Account Deduplication
When the same account is added using multiple sources (i.e., provider accounts) the account deduplication process prevents the same account from being added multiple times to the Yodlee Platform. The associatedProviderAccount attribute in the API responses is used to identify deduplicated accounts.
- Deleting the primary provider account – A check for deduplicated item accounts are done and if any exist, then that item account is linked to the secondary provider account.
- Deleting the secondary provider account – A check for deduplicated item accounts are done and if any exist, then the link between the MSA and item account is removed but the deduplicated account is kept active.
- Deleting the item account – The item account is deleted from the platform and will no longer be returned in any API responses.
YODLEE API — NEW FEATURES
Introducing API Key-based Authentication
A new API key-based authentication is introduced to access Yodlee APIs. Some of the key features follow:
- API Key – The API key is the identifier of the cobrand and will be assigned to you when you sign up or sign a new contract with Yodlee. This API key should be used to generate an Authentication token that will be used to access Yodlee APIs. If required, this API key can be revoked and a new key can be generated.
- Token – The JSON Web Token (JWT) must be signed using the RS512 algorithm to make sure it is secure. The JWT token should contain information about the API key and a user identifier. Also, this JWT token will have to be signed using your own private key and should be passed as an Authentication header with every API call.
- Public or Private Key – A public key of your private/public key pair will have to be uploaded to the Yodlee Developer Portal. This private key will have to be used to sign your token so that Yodlee servers can validate the token and make sure it is coming from a legitimate source.
Note: To reduce the onboarding or set up time, for a free sandbox account in the Yodlee Developer Portal, the user will be given an option to download a private key that can be used to sign the token.
Cobrand or User Credentials Deprecated
The cobrand or user credential-based authentication is deprecated with the introduction of the API key-based authentication for non-SAML customers.
YODLEE API — ENHANCEMENTS
Support Passing of Datasets in Yodlee API v1.1
Add/Update providerAccounts APIs have been enhanced to request data using the dataset name to enhance the developer experience.
| EXISTING DATASET INPUT | ENHANCED DATASET INPUT |
|---|---|
| “dataset” : [ { “name” : “ACCT_PROFILE” }, { “name” : “BASIC_AGG_DATA” }, ] |
“datasetName” : [“ACCT_PROFILE”, “BASIC_AGG_DATA”] |
This is an alternative to the existing capability to request data; the existing implementation will not be impacted. When requested in this format all the attributes that are configured for the customer under that dataset are considered.
nextUpdateScheduled Attribute in Yodlee API v1.1
The nextUpdateScheduled attribute enables the customer to know when the next auto- refreshes are scheduled so that they can anticipate the new incoming data from Yodlee.
The following Yodlee API v1.1 endpoints have been enhanced to provide the auto-refresh schedules:
- GET /providersAccounts
- GET /providerAccounts/{providerAccountId}
- GET /accounts
- GET /accounts/{accountId}
Holder Details Dataset Enhancements
-
Company as One of the Holders
The holder entity under the GET /accounts and GET /accounts/{accountId} Yodlee API v1.1 endpoints have been enhanced to return a company as one of the holders. -
New Values for the Ownership Attribute
The ownershipType attribute provider in GET /accounts has been enhanced to provide the following new values:
| VALUE | DESCRIPTION |
|---|---|
| AAS | Authorize Account Signatory |
| BUSINESS | Business |
| DBA | Doing Business As |
| TRUST | Trust |
Note: The new values are used only if Yodlee identifies the account belongs to a business or company.
Webhooks Enhancement
The refresh and data extracts webhooks notification payload will be posted in the JSON format to the callback URL. The content type will be application/json.
Note: The existing customers will continue to receive the payload as a key-value pair with payload as a key name.
DataUpdates Webhooks — Split Notification
- The notification framework has been enhanced to split the notifications when the number of users in the payload exceed 2,000.
- All notifications pertaining to an interval are generated simultaneously but have different notification IDs.
- The split notification enhancement is available in both Yodlee API v1.0 and Yodlee API v1.1.
- This enhancement benefits by providing a reliable payload every time which can be well managed by your servers
SAML Authentication Enhancement
- The SAML user login API have been enhanced to perform registration.
- Customers can invoke the SAML user login API to authenticate and register their users.
- This avoids the processing overhead on your side to ensure that the users are registered with Yodlee.
- This enhancement is available in both Yodlee API v1.0 and Yodlee API v1.1.
- The SAML user register API will continue to register users in the Yodlee system to ensure backward compatibility.
Add or Update — Yodlee API v1.1 Enhancements
- Consistent Availability of MFA Information
The Yodlee infrastructure is enhanced to provide MFA requests consistently in the GET providerAccount/{providerAccountId} API endpoint until the MFA information is received.
This enhancement ensures that there is no loss of MFA request information until the user responds with inputs to the MFA request. This results in the successful completion of the add or update account process. - Removed the Mandatory Constraint of Label Input
For a question and answer based provider site, the mandatory constraint of passing the label field as input in the PUT /providerAccount endpoint during the add and update process has been removed.
You can invoke the PUT /providerAccount API endpoint with id and value fields in the input similar to the other MFA types. You can now have a single implementation for all the MFA types.
YODLEE FASTLINK — NEW FEATURES
Real Estate Improvements
Support is now available to identify unique addresses. The account deduplication process avoids storing multiple accounts with same addresses in the Yodlee system. For a new account, if the user enters an address that was already provided for an existing real estate account, Yodlee will only refresh the existing account and display an appropriate alert message(s) to the user.
This improvement only applies to the auto-calculate feature and not to the manual value-based accounts.
Support for Challenge Deposit Verification in Data Service Flow
Data service flows now support enabling the challenge deposit account verification with a few customization options. Consumers can now switch to challenge deposit verification at any point in the verification flow. For details about challenge deposit verification, refer to the FastLink Overview.
Minor Bug Fixes and Improvements
- In the verification flow, one can now decide between the display of toggle and radio buttons, but whether or not to display them at all.
- In the aggregation + account profile flow, the account selection screen has changed from Select an account for fund transfers to Select the accounts you want to use.
- When integrating with FastLink for verification, when a single account is present, the status message is now changed to SUCCESS instead of SELECTION_COMPLETE. Similarly, when one of the accounts has failed the status is identified as PARTIAL_SUCCESS.