The following flow describes the typical way an FIU, i.e. a business who wants some type of financial data from a user, requests for the information. 

  1. First, the FIU makes a data request, which is routed to an Account Aggregator (AA).

  2. The AA delivers the request first to the consumer, who reviews their request for their data. Say, a lender FIU has a one-time request for a borrowers’ bank statement for the last 3 months, this request will be presented to the user with all details like—

    1. the reason to ask for this data, i.e. approval of loan

    2. the type of data requested for, i.e. bank statement

    3. the duration for which data is fetched, i.e. 3 months 

    4. and if this is a one-time request for data, i.e. yes

  3. The user can review details and decides to consent to or reject the data request.

  4. If they consent to the request, the request is forwarded to the FIP who can provide the user’s data, the approval by user to share their data is checked and the data is forwarded from the FIP—in the above example, a bank—with the lender.

  1. As can be seen, the data request carries details about the type of data, how long the FIU needs it for, and how they plan to use it. A user can treview these details before deciding to consent to or reject the request. The user can also decide to withdraw consent for a previous request. This way, the user remains the custodian of their own data.

    Are you already integrating with AA? Check out the AA Integration Guide here.