Introduction
The service uses a v2 authentication token and requires it to be generated with scopes as disclosure:reads, institution-users:read for getting the disclosures.
For adding/updating disclosures, disclosures:write is required in the body.
Financial institutions are required by law to disclose aspects of an account holder’s banking services that need their knowledge and permission. They must also maintain a record of their response (whether they accept or decline the disclosure). Allowing consumers and businesses to control important aspects of their banking relationship instills confidence and enhances their satisfaction. And beyond regulation, it’s simply good business.
An example of such a disclosure is the request for an individual’s acceptance of terms and conditions when enrolling for digital banking. Another would besigning up for electronic statements.
The Disclosures API is a set of basic services used to manage two types of disclosure records, including:
- Financial institution disclosures: Facilitates the creation, retrieval, update and deletion of the disclosures, including their nature, text, status, etc.
- User disclosure responses: Facilitates the creation, retrieval, update and deletion of an individual’s response to the disclosures, including whether they accepted or declined.
The Disclosures API enables end users to:
- Remain informed about terms and conditions, legal requirements and other aspects of their banking experience.
It enables financial institutions to:
- Gain the trust of their customers and members by clearly stating terms and conditions, etc. and complying with regulations.
It enables the developer to:
- Manage all aspects of disclosure records through one service.
While the technical documentation in the API specs section describes the endpoints (or ways to call the API with different parameters to execute different actions), the following provides a simplified list of use cases for disclosures.
Managing financial institution disclosures: Financial institution disclosure records contain the data elements necessary to present users with information (such as a terms and conditions document) and to request their response.
The Disclosures API provides the methods to manage these records, including:
- Create: Used to create new disclosure records. The name type, content, status and other elements are created to prepare a disclosure for use in an application.
- Read: Used to call up a disclosure record, most commonly when required in a workflow. The read method is invoked when a user is prompted to read and accept a disclosure.
- Update: Used when any aspect of the disclosure record must be updated (e.g., when the language of one has changed).
- Delete – Used to delete any disclosure records that are no longer needed.
Managing user disclosure responses: Maintaining the records of user responses to disclosures is both a legal requirement and a good business practice. For example, when a user accepts a disclosure to begin using online statements, your system needs that acceptance on record to ensure delivery to the customer or member, as requested. In the event of a dispute, you’ll need to produce the acceptance (or decline) record indicating the user’s response.
The Disclosures API provides the following methods to manage these records:
- Create: Used to create new user response records. The response is linked to the financial institution’s disclosure, to ensure the affected account and the date and time of the response. The response itself is recorded to indicate whether the user accepted or declined.
- Read: Most commonly used when running a process related to a disclosure (e.g., if the user accepted a disclosure to receive online statements, then the process for creating online statements would need to check off that response).
- Update: Used to manage changes, such as the reversal of a previous answer to a disclosure. For example, a user might opt into receiving online statements and later decide to return to paper statements. The time and date of this change are also recorded through this method.
- Delete: Used to delete any user disclosure response records that are no longer needed.
Getting Started
Candescent’s APIs support financial institutions worldwide. They can empower financial institutions and their partners to build valuable digital banking experiences.
It’s important to work with your Candescent representative to get officially onboarded to DevX for access to these APIs. Once onboarded, you’ll be able to implement your application, access shared and secret keys and begin testing the APIs.
After all the legal and compliance partnership agreements are in place, we'll set you up with your Authentication API client account. This will grant you access to a unique secret key that will be your ticket to the authentication API and staging and production environments.
The service available through the Candescent Digital Banking Developer Portal provides a token for the grant type:
Client Credentials
- Used for trusted server-side applications
- Sending a request passes a key-and-secret pair assigned to your application
- Since the token is issued in the context of a Financial Institution (FI) rather than a user, no end-user login is required
- Response provides the Bearer Token to be used to call other DevEx APIs
Steps to getting started:
- Sign up and/or Login in for authentication
To make your first API request, you'll need toself-register by clicking the Sign Up button. Then, click the link in your welcomeemail to verify your emailaddress. - Review API documentation and request postman collections
Your Candescent representative will be able to email you the Postman collection for an API you are interested in. You may reach out directly or add the specific API to your favorites to alert your representative.
- Test APIs in Postman
In addition to the sample apps, a test drive environment is available to help you visualize the APIs. Using the JSONcollection and Postman, you’ll be able to see API requests working in action and view the information required to make them.
This will also allow you to experience actual API behavior prior to beginning your integration. For a deeper dive into Postman, view additional reference material here.
Authentication
Authentication proves that you are who you say you are. Authentication tokens identify a user (the person using the app or site).
You‘ll need the following items to set up basic authentication:
- Developer Experience account
- Sandbox environment with an organization
- Shared Key
- Secret Key
Generating your Secret Key
You’ll need a bearer token or an API security key to authenticate API calls. A secret key serves as a secure token to authenticate and authorize requests. Unauthorized use of a secret key could potentially cause a security breach. Thes ecret key holds the error token used to access real data through the API.
Visit our guide on authentication to learn more.
Before you begin, you‘ll require a unique client_id and client_secret for your app. Notify your implementation manager or PossibleNOW Support atsupport@possiblenow.com to request an OAuth client_id and client_secret. Include your My Preferences Client ID and the environment (staging (sandbox) or production) for which you want to generate the credentials in your request.
These credentials must be treated securely.
Getting Started
While the technical documentation in the API Specs section describes the endpoints (or ways to call the API with different parameters to execute different actions), the following provides a simplified list of use cases for Authentication:
The service available through the Candescent Digital Banking Developer Portal (providestokens for two different grant types:
Client Credentials
- Used for trusted server-side applications
- Sending a request passes a key-and-secret pair assigned to your application
- Since the token is issued in the context of a Financial Institution (FI) rather than a user, no end-user login is required
- Response provides the Bearer Token to be used to call other DevEx APIs
Password
- Best for first-party native applications (such as the FI’s own mobile application)
- Request is sent with key-and-secret pair plus the customer’s username and password
- Response provides Bearer Token to be used to call other DevEx APIs