High Level Design

High-level Design

AA acts as an intermediary and helps connect the Customer to multiple Financial Information Provider (FIP)s through standardized API interfaces. In this process, the NBFC-AA ecosystem needs an interoperable, consent-driven architecture, and a set of standard APIs that will facilitate secure, seamless, and consented sharing of various kinds of financial information.

The below diagram is the high-level design diagram which shows various interfaces and system interactions in the AA ecosystem as follows:


👍

Benefits of this Architecture

Security : Ensures secure sharing of financial information with consent-driven mechanisms.
Seamlessness: Facilitates smooth interactions between Customers, AA, and FIPs.
Flexibility : Asynchronous API design allows for improving overall performance & responsiveness.

  1. Customer Interaction with AA for Services:

    • Customers initiate interactions directly with the AA to request various services.
    • This includes tasks such as account discovery, linking, and managing consent for data usage.
  2. AA Client Component:

    • The AA Client is a software component provided by AA to facilitate interactions between customers and AA services. It acts as an intermediary layer that customers can use to interact with AA.
    • The AA Client can interact with AA in different ways:
      • Direct Interaction: Customers may directly interact with AA through applications provided by AA.
      • API Interaction: Customers can also interact with AA via APIs exposed by AA, which are accessed through the AA Client.
  3. Account Linking and Consent Management:

    • Account Linking: Customers securely link their accounts to the AA.
    • Consent Management: Customers manage consent agreements, deciding how their data is used or shared by AA.
  4. Asynchronous API Design:

    • The architecture employs an asynchronous API design for interactions between customers and AA.
      This design involves using callback notification APIs.

📘

When customers initiate requests (e.g. consent management) through the AA Client, they do not need to wait for an immediate response from AA.

Instead, callback notification APIs are used to notify the customer asynchronously when the requested operation is completed or needs attention.

  1. Implementation Forms of AA Client:
  • The AA Client can be implemented in various forms to cater to different platforms and integration needs:
    • Software Development Kits (SDKs) or Libraries: These are integrated into customer applications to enable direct interaction with AA services.
    • Standalone Applications: AA may provide standalone web-based or mobile applications for customers to interact with its services.
    • API Integration: For developers and advanced users, the AA Client may also facilitate direct interaction through authorized API calls to AA services.

Credits: ReBit