Get List of Customer Accounts
After a customer has added accounts the list of accounts they have added can be retrieved using the Get Customer Accounts Service.
Initial Aggregation of Accounts
After an account is added to the system an initial aggregation must be made on the account in order to retrieve transactions. The first time aggregation occurs Finicity will retrieve the last 6 months worth of transaction data from the Financial Institution for the account (where 6 months of data is supported from the FI). To aggregate the accounts you can aggregate all of them for the customer by calling Refresh Customer Accounts or to aggregate a set of accounts under a specific login set you can use Refresh Institution Login Accounts by using the instititutionLoginId.
Get Accounts Options
Here are a few other Get Account API options to get account information.
Customer account records have a lot of different data points that can be used in your application. There are a few important pieces of information to note that can be used to properly identify accounts you will want to use in your application and some data points that will help you best organize account data inside your application. See the article Customer Account Record for a full list of data points in the account record.
Id – Store this unique finicity account identifier for future account data retrieval and organization
institutionId – The id of the financial institution. This is useful for organizing account by financial institution.
institutionLoginId – This is the unique identifier for a set of accounts that are added under the set of login credentials. This is important to display accounts grouped by this identifier to give the end user the proper context to their accounts they added with their login credentials.
Account Type – This will tell if you if the account is a checking, savings, loan, etc. This can be useful for determining how you will use them in the app.
After transactions are loaded into Finicity from the initial aggregation you can retrieve the transaction via the Get Customer Transactions Call. You can also retrieve transactions by individual account.
Every night Finicity aggregates transactions for all customer accounts. Your application can then retrieve those transactions. We recommend retrieving the last several days of transactions as sometimes transactions can be posted slightly delayed from their posted date. With the Finicity transaction ID, you can identify transactions you have already retrieved versus the new transactions.
Finicity transaction records will have a posted transaction date, amount, description or memo. Other transaction fields will be present based on the account type and based on the availability of the data point at the financial institution. Finicity will also include a normalized payee and categorization data for the transaction. See the associated articles for more details on all the data points available.
How do pending transactions work?
A pending transaction is a transaction that has been initiated but has not been cleared or posted by the institution. Pending transactions are ephemeral. Each connection to an institution will capture pending transactions that are available at that time; if any of those transactions are not found in a subsequent connection, they will be deleted from the data.
There is usually not an association between the pending transaction and the posted transaction that comes later. If there is, then the status of the transaction will be updated from pending to active to indicate that the transaction has posted. The transaction details such as amount and date could update at that time as well.
What are shadow transactions?
Some institutions continue to modify or delete transactions long after they are first posted to the institution’s data feed. Finicity has added the ability to identify transactions that were found in an earlier aggregation of an account, but are not found in the institution’s current data source. These transactions are marked as status “shadow”.
The client app may choose how to handle shadow transactions. For example, it could choose not to display these transactions at all; to remove them from the app’s data store; to display a button so the customer can confirm that the transaction should be removed; or to ignore the field entirely.
See the article Shadow transactions for the latest details.