SahamatiNet Router serves as an additional layer on top of the AA network, offering extra services and policies. By integrating with the Sahamati Router, FIUs, FIPs, and AAs can seamlessly connect with all other entities within the Router. This eliminates the need for multiple integration points, significantly reducing the integration and operational efforts for members

Comprehensive Technology Infrastructure – SahamatiNet

SahamatiNet - Services on Observability

MIS :

Daily reports on Discovery, Linking, Consent, and data fetch, generated from the Router’s meta data. Will be more accurate that currently available due to varying cadences, formats, incorrect data and naming conventions.

Network Health :

Complete picture of health of FIP and AA applications derived from a single source of truth. Avoids overlapped calls from AAs to the FIPs and ecosystem health reporting is not dependent on vagaries of reporting.

SLA Reporting :

• Report on SLA Adherence for each scenario’s success case, error rate for AAs and FIPs.

• Need to define and agree SLAs for each ecosystem participants and report on adherence and Report on non-adherence to SLA commitments

NOC Support :

• Sahamati NOC Support using Network Health metrics and SLA Adherence

• Facilitates proactive action to correct ‘sick’ nodes

• Grievance Redressal

Technical Audit :

• API Telemetry

• Tracking of changes in Ecosystem such as onboarding of REs, ad

Billing and Recon :

Generate data fetch statements to support downstream billing & any reconciliation efforts amongst participants bilaterally

Introduction to SahamatiNet

SahamatiNet is the technological infrastructure developed and maintained by Sahamati to support the Account Aggregator (AA) ecosystem. It comprises a set of specifications, Application Programming Interfaces (APIs), and services aimed at improving the ecosystem's performance, trust, and reliability. By establishing a robust infrastructure, SahamatiNet addresses key challenges such as interoperability, data compliance, data quality, and operational efficiency, thereby ensuring a seamless and trustworthy experience for AA ecosystem entities involved.

Current AA Network Mode - Many to Many Integrations

The integration and interoperability within the AA ecosystem are significantly simplified through the use of SahamatiNet, a unified platform that serves as a central hub for all participants—FIUs (Financial Information Users), AAs (Account Aggregators), and FIPs (Financial Information Providers). Traditionally, these entities would have to establish separate connections and integrations with one another, each facing unique challenges related to data exchange, security, and compliance with standards. However, with SahamatiNet, this complexity is reduced as all participants—FIUs, AAs, and FIPs—now only need to integrate with this single application.

At present, the integration model within the Account Aggregator (AA) ecosystem involves multiple connections:

• (FIU x AA): Financial Information Users (FIUs) integrate with Account Aggregators (AAs).

• (AA x FIP): Account Aggregators (AAs) also integrate with Financial Information Providers (FIPs).

This results in a complex network of individual, point-to-point connections between participants, which increases the integration effort and maintenance overhead.

Interoperability

SahamatiNet serves as a central interface that significantly enhances interoperability within the AA ecosystem. It allows all participants—FIUs, AAs, and FIPs—to interact seamlessly by leveraging a unified set of shared protocols and standards defined by ReBIT. By integrating with SahamatiNet Router, each participant can effortlessly connect with and exchange data with other members of the ecosystem, without needing to establish multiple individual integrations. This centralised approach reduces complexity and eliminates the need for separate, technical connections, ensuring consistent data handling, security, and simplified interoperability across all participants.

The platform standardises communication between all roles, facilitating smoother and more efficient connections. Participants no longer have to navigate through complex and disparate systems to access necessary data or services. Instead, they rely on SahamatiNet Router to manage interactions, significantly simplifying integration efforts. This approach leads to a more streamlined and scalable model for data exchange, security enforcement, and access management, fostering a cohesive ecosystem. By consolidating previously fragmented connections into a single, unified application, SahamatiNet Router makes interoperability faster, more secure, and more efficient for all participants in the AA ecosystem.

However, as entities integrate with SahamatiNet, this integration model will be streamlined. The number of necessary integrations will be significantly reduced to a simpler structure:

• (FIU + AA + FIP): Financial Information Users (FIUs), Account Aggregators (AAs), and Financial Information Providers (FIPs) will now interact with one central service (SahamatiNet). This centralisation simplifies the communication process, reduces the number of direct integrations, and enhances the overall efficiency of the ecosystem.

Delegation of Trust

The AA ecosystem shifts from a traditional bilateral-trust model to a more scalable network-trust framework, where trust is centrally managed through SahamatiNet. This framework guarantees interoperability across all participants—FIPs, AAs, and FIUs—by applying consistent security standards and protocols. Instead of each participant individually establishing trust with others, trust is delegated to SahamatiNet, ensuring secure and seamless interactions throughout the ecosystem.

To maintain this trust, FIPs are required to subject SahamatiNet to a rigorous onboarding process before integrating with it, ensuring the platform meets their security and operational standards. Once FIPs are onboarded, Sahamati applies the same level of scrutiny when onboarding AAs. Similarly, AAs apply rigorous checks when onboarding FIUs, and once an FIU passes this process, Sahamati applies the same level of rigor to onboard the FIU to SahamatiNet. This delegation of trust streamlines the process, enabling more efficient and reliable interoperability across the entire AA ecosystem.

SahamatiNet Router

Interoperability is a core challenge in any data-sharing ecosystem. The Router acts as a bridge to ensure smooth and standardised communication between various ecosystem members using ReBIT APIs. When a request is made by one member to another (such as an FIU requesting data from an FIP), the Router ensures that the API requests and responses are correctly routed and formatted. This service is crucial for ensuring that no matter what system or infrastructure a member uses, the interaction remains standardised and interoperable across the network.

Key Features:

• Facilitates interoperability between ecosystem members.

• Routes and standardises API requests and responses.

• Simplifies cross-ecosystem communication by eliminating compatibility issues.

Current API reference

The following diagram shows the current flow between FIU and AA flow for Consent API. With the current structure, the API requests are sent to the respective recipient member directly. This requires each member to understand the metadata of the recipient member and use their base path while sending.

Using Sahamati Router APIs

Sahamati Router simplifies the process for members to send requests to any recipient by simply including the recipient identifier (x-recipient-id) in the header, under x-request-meta. The Router will then redirect the request to the corresponding recipient. This update must be implemented across all ReBIT APIs in the respective regulated entity's application.

Currently, the Router is fully implemented with all APIs compliant with ReBIT specifications v2.x.

Central Registry (CR)

The Central Registry is a core service in the AA ecosystem, provided by Sahamati, which serves as a directory for all participants—Account Aggregators (AAs), Financial Information Providers (FIPs), and Financial Information Users (FIUs). It provides essential information about each participant, including their public IP addresses and public keys, enabling secure and interoperable communication within the ecosystem.

The Central Registry offers an API that allows participants to access details of other members, subject to role-based access restrictions. These roles are defined through identity tokens issued by Sahamati, ensuring that each participant can only access relevant information. For instance, AAs can fetch details of FIPs and FIUs, while FIPs and FIUs can retrieve information about AAs.

Additionally, the Central Registry is closely integrated with the Token Issuance service, which provides each participant with a short-lived JSON Web Token (JWT) for secure API calls across the ecosystem. This JWT is used to authenticate each participant and must be refreshed every 24 hours.

The Central Registry ensures seamless interaction within the AA ecosystem by making vital participant information easily accessible and securely managed.

Identity Access Management (Token Service)

The Identity and Access Management (IAM) system within the AA ecosystem is responsible for ensuring secure and authorized access to ecosystem APIs. It manages participant roles, such as AA, FIP, or FIU, which are assigned during registration and embedded in the identity tokens issued by Sahamati. These roles govern access to services and ensure that participants can only access information they are authorized for.

To facilitate secure interactions, IAM utilizes Access Tokens—short-lived JSON Web Tokens (JWT)—to authorise participants when they access ecosystem APIs. The Access Tokens, linked to the participant's role, ensure that only authorised individuals or entities can retrieve specific data or interact with services. Through role-based access control and token-based authentication, IAM safeguards the ecosystem's integrity and protects sensitive data while enabling secure communication among participants.

SahamatiNet POC Onboarding Checklist

1. Register as a Ecosystem Member for POC

   1. Identify the key fields needed for registration.

      1. Choose your member type: Account Aggregator (AA), Financial Information Provider (FIP), or Financial Information User (FIU).

      2. Provide the following organisation details for the Central Registry (CR):

         • Entity ID (unique identifier)

         • Base URL for your service

         • RSA Public Key for secure communication

         • IP Address, Inbound and Outbound Ports (for production; optional for UAT and Sandbox)

      3. Designate a user (preferably with a service email account) to manage the entity as an admin in CR and IAM.

   2. Complete the Google Form for Registration to onboard with the Central Registry (CR).

2. Verify and Set Up User and Entity Access Tokens

   1. The designated user will receive an email with a password reset link.

   2. Reset the password and complete the account setup.

   3. Generate the User Access Token using the user’s email and new password.

   4. Use the User Access Token to read the entity’s secret from the Sahamati IAM API.

      1. If needed, reset the secret using the designated API.

   5. Use the entity secret to generate the Entity Access Token for ReBIT APIs.

   6. Refer to the section on these APIs here

3. Integrate with SahamatiNet Router in Sandbox

   1. Understand the required changes for integration with the Router.

      1. Sahamati Router simplifies the process by allowing members to send requests to any recipient by adding the recipient identifier (recipient-id) in the header under x-request-meta. Refer here for more details.

   2. Changes of additional step of onboarding in your application

      1. With the transition to integrating with the SahamatiNet Router, the onboarding process for FIUs (Financial Information Users), AAs (Account Aggregators), and FIPs (Financial Information Providers) is no longer necessary. Previously, this step was essential for establishing peer-to-peer trust and enabling communication within the AA ecosystem. However, with Router integration, trust is managed through technical means, eliminating the need for additional onboarding on your side.

      2. As an AA Ecosystem participant, you can bypass the manual onboarding for FIUs, AAs, and FIPs in your application. These participants would undergo the required compliance through SahamatiNet before interacting with other entities via the Router. This change streamlines the integration process, removing the need for extra code or configuration, and improving the efficiency and ease of connections across the AA ecosystem.

      3. Note that while the technical integrations are now handled through the Router, the necessary commercial agreements between AA ecosystem participants remain unchanged and will continue as they are.

   3. Review ReBIT workflows relevant to your entity using the Router.

      1. Account Discovery and Linking workflows

      2. Consent workflows

      3. FI Request workflows

4. Integration with Simulators

   1. Test and validate the Router's functionality with ReBIT workflows tailored to your entity type by using the integration simulators in the sandbox environment (FIU, AA, FIP). You can also test this with your own simulators, if you have them. Please be sure to include the simulator details in the Google form provided above. We will onboard it for validation in the Sandbox environment as part of the POC.

   2. Refer to the section on how to use SahamatiNet simulators here and respective simulators links below

      1. AA Simulator

      2. FIP Simulator

      3. FIU Simulator

5. Validate Integration with Simulators and Regulated Entities

   1. Conduct tests with other onboarded entities in the sandbox environment to review all integration points and ensure seamless operation.

   2. More details on this step will be provided as we progress through the POC.

By following these steps, you will successfully onboard and integrate with SahamatiNet in the sandbox environment, ensuring compliance with ReBIT specifications and the AA ecosystem standards

The Account Aggregator (AA) infrastructure is a sophisticated technological framework designed to revolutionize data sharing across the financial sector in India. The collaboration among financial sector regulators (FSRs)—Reserve Bank of India (RBI), Securities and Exchange Board of India (SEBI), Insurance Regulatory Development Authority (IRDA), and Pension Fund Regulatory Development Authority (PFRDA)—under the Financial Sector Development Council (FSDC) has aimed to establish a seamless, secure, and efficient data-sharing mechanism.

The Reserve Bank Information Technology Pvt Ltd (ReBIT), a wholly-owned subsidiary of the RBI, was authorized to establish technology standards for the ecosystem. This regulatory framework established a high-level architecture, and the market was kept independent of operationalizing the data-sharing mechanism. This market-driven approach has led to the formation of Sahamati as an industry alliance to collaboratively build the necessary procedural and technological foundations for the AA ecosystem.

SahamatiNet is the technological infrastructure developed and maintained by Sahamati to support the Account Aggregator (AA) EcoSystem. Hosted in a secure, highly available, and scalable environment, this technological infrastructure ensures the robustness and reliability of the AA EcoSystem. The infrastructure aims to engender trust, build visibility in ecosystem health, offer implementation support and grievance redressal mechanisms, foster a culture of compliance, and enable efficient integrations across the ecosystem. Sahamati has co-created these crucial technology artefacts with the collective intelligence of the ecosystem to serve its diverse needs.

Delve into the functional aspects of the SahamatiNet:

Network Trust

Sahamati maintains a Central Registry (CR) to facilitate the discoverability of public information related to each member endpoint. CR is a comprehensive database listing all authenticated and authorized entities within the AA ecosystem. It ensures that only verified Account Aggregators, Financial Information Providers (FIPs), and Financial Information Users (FIUs) can participate. CR empowers eligibility verification and streamlines the onboarding process onto the network, fostering stakeholder confidence and trust.

The CR is supported through a token service that ensures the validity & reliability of end-point information. It enhances security by managing secure and efficient data exchanges between entities. It issues and validates tokens, ensuring that all data requests and transfers are authenticated, authorized, and encrypted. By codifying network-level authorization rules, the token service safeguards against unauthorized access and enhances trust within the network.

Network Health

Sahamati has built a network health monitoring infrastructure that provides visibility into various parameters of health in the ecosystem. Through continual tracking of the performance of the ecosystem, the system equips identification of potential issues such as downtimes or implementation bugs. It enables proactive management and rapid resolution of any disruptions, ensuring smooth and efficient operations. Complementing the monitoring system are the Management Information System (MIS) dashboards, which offer real-time visibility into key metrics and performance indicators. These dashboards provide detailed insights into volumes of accounts linked as well as consents fulfilled.

Certification

Sahamati is committed to fostering a culture of compliance in the Account Aggregator (AA) ecosystem. It has institutionalized a certification process before onboarding members to foster a standardized and secure ecosystem. Members can opt for this certification service to ensure adherence to the Technical Standards set by ReBIT and simplify compliance. Sahamati has strategically empanelled organizations to provide independent certification services, guaranteeing compliance and impartial assessment. Certification also fosters trust and enables easy integration, facilitating seamless interoperability and reducing integration friction.

Network Support

Sahamati equips the ecosystem with implementation support and grievance redressal mechanisms. During the implementation phase, Sahamati provides comprehensive support, offering technical assistance, guidance, and resources to ensure smooth onboarding and effective utilization of the infrastructure. A dedicated support application is available to address grievances and resolve issues faced by members. This mechanism ensures that any problems are promptly addressed, maintaining member satisfaction and trust in the ecosystem.

SahamatiNet aims to create an interoperable, customer-centric ecosystem through a secure, transparent, and efficient infrastructure. This holistic infrastructure ensures the reliability, security, and growth of the AA ecosystem. The infrastructure enhances the efficiency of data-sharing transactions and promotes trust and collaboration among all stakeholders, driving the overall success of the AA ecosystem.

Currently, SahamatiNet is dedicated to addressing key ecosystem challenges, including interoperability, data usage compliance, and operational efficiency, to provide a seamless experience for AA ecosystem members. The following are the primary focus areas of SahamatiNet:

• Interoperability: Enable ecosystem members to connect seamlessly with all other Sahamati Network entities. This eliminates the need for multiple integration points, significantly reducing the integration and operational efforts for members.

• Fair Use Compliance: FIUs and AAs are expected to align their consent usage within ecosystem-defined boundaries to ensure the fair use of AA. SahamatiNet aims to develop a programmatic, policy-based automated framework that ensures compliance with fair use policies regarding customer consent and data.

• Network Observability: SahamatiNet aims to scale the current network health monitoring system to a comprehensive infrastructure that provides real-time data access and monitors fraud to aid efficient dispute resolution, billing & reconciliation, and tracking network usage.

• Policy Development and Advocacy: The organization is engaged in developing policies and advocating for regulatory frameworks that support the growth and sustainability of the AA ecosystem.

• Additional Initiatives: Sahamati is continually exploring and implementing other initiatives to support and enhance the AA ecosystem's functionality and resilience.

However, it is important to adopt and implement technological solutions alongside governance measures to expedite the resolution of these challenges.

Sandbox Onboarding

To participate in the SahamatiNet Router in the Sandbox, an entity (AA, FIP, or FIU) must ensure its API implementation is ReBIT standards-compliant. This ensures that the entity's APIs meet the necessary interoperability standards for the AA ecosystem and can be tested via the SahamatiNet Router.

The onboarding process involves submitting the Entity (member) information such as

For Ecosystem Member Type: Specify whether you represent an AA, FIP or FIU.

• Account Aggregators (AA) : Entities that facilitate the secure sharing of user financial data between financial information providers (FIPs) and financial information ussers (FIUs)

• Financial Information Providers (FIP) : Entities that hold user financial data, such as banks, NBFC, etc.

• Financial Information Users (FIU): Entities that seek user financial data to provide value-added services like loans, wealth management, and more.

For IP Address, Inbound and Outbound Ports: Network details for connecting with the AA ecosystem are required for Production, optional for UAT and Sandbox.

The Designated User of the entity information such as

Designated User: Contact details of the representative responsible for generating and managing the client secret in IAM (Token Service). It is recommended to use a service account email for the long-term management and consistency.

If you're experiencing difficulties accessing the Google form from your organization's network, you can alternatively generate the following JSON request and email it as an attachment to sandbox@sahamati.org.in. Please use the subject line: Onboarding to SahamatiNet Router POC: and make sure to include the designated user's email ID and full name for each entry.

Fetching Regulated Entities REs metadata using Central Registry (CR)

A RE should fetch the metadata of the other REs to interact with them through ReBIT APIs to handle the AA ecosystem functionalities. Sahamati provided the CR APIs to access the REs metadata. Here is the sequence diagram for Fetching REs metadata.

API Collection:

Each member of the Sahamati Network will be onboarded with a designated user who holds an admin role to manage the entity’s profile and secret.

• During the onboarding process, the designated user will receive an email containing a verification link. After email verification, the user will be prompted to set a password, completing the account activation process.

• Once the password is set, the user can generate the User Access Token by providing their email and the new password. This token is used for authenticating the entity’s secrets.

• The designated user can then use the User Access Token to access the entity’s secret and, if necessary, reset the secret.

• Finally, the entity secret is used to generate the Entity Access Token, which is needed for interactions with the ReBIT APIs within the AA network.

Entity Token Generation use case

The Regulated Entities (REs) should generate the Access Token using the Token API from Sahamati for accessing and authentication of any APIs in the AA ecosystem including Sahamati APIs.

Here is the sequence diagram for the Token Generation Process.

Below are the Base URL of each environment to use IAM APIs.

Please note that the following documentation displays the Base URLs from the Sandbox environment. Ensure you use the appropriate Base URLs depending on the environment you are working in.

Token Generation APIs:

API Postman Collection:

Below is the Sandbox Environment file for SahamatiNet Services

Member Secret Management APIs

API Collection:

The following pages provide an overview of these API implementations.

Implementing Code Changes for Router Integration

Outlined below are the changes that members need to make to their implementation to use the SahamatiNet Router.

• Use the following Sahamati Router API endpoint as base path for all the requests.

• Do note the Router API endpoint URL mentioned above is used for Sandbox, the respective URL for each environment (UAT and Production) will be updated when we progress to next environments.

• Add the recipient ID under the new header x-request-meta with recipient-id in a JSON object which is the identifier of the receiver to whom the API call needs to be forwarded.

  • The value of the x-request-meta is Base64 string of the JSON object with recipient-id.

  • This structure helps us to easily extend the JSON object by adding the required attributes for future use cases.

The receiver could be any of the participant, FIU, AA or FIP.

These header changes need to be implemented for communication between FIU and AA, AA and FIP, FIP and AA, as well as FIU and AA.

Service URLs for the Sandbox

Service Name and their URLS

Public Key

IAM (Token Service)

Central Registry (CR)

Router

API Collection:

In the Account Aggregator (AA) ecosystem, secure data sharing is facilitated through three key workflows, each governed by standardized ReBIT APIs. The process begins with User Login to AA for Account Discovery & Linking, where users provide identifiers such as mobile numbers to identify and connect their financial accounts across multiple institutions; the linking is authorized via a One-Time Password (OTP). Following this, the Consent Workflow enables Financial Information Users (FIUs) to obtain explicit user consent for accessing their financial data from various Financial Information Providers (FIPs), ensuring compliance with stringent privacy standards. Finally, once consent is granted, the Financial Information (FI) Request Workflow allows FIUs to securely request financial data from FIPs through the AA, ensuring that only authorized data is retrieved and shared, thereby maintaining privacy and data integrity throughout the process.

Account Discovery & Linking

Account Discovery & Linking allows users to identify and link their accounts across multiple financial institutions. This process is initiated when a user provides their mobile number or other identification, which the Account Aggregator uses to query Financial Information Providers (FIPs) for linked accounts. Upon identification, the user is prompted to authorize the linking via an OTP (One-Time Password). ReBIT APIs facilitate the communication and data flow between the AA, FIU, and FIP during the discovery and linking phases.

Consent Workflow

The Consent Workflow is at the core of the Account Aggregator (AA) ecosystem. It governs how a Financial Information User (FIU) obtains explicit consent from the user to access their financial data held by various Financial Information Providers (FIPs). This workflow ensures that data sharing is fully authorized by the user, adhering to stringent data privacy regulations. The consent mechanism follows a standardized flow, involving the FIU, AA, and FIP, where ReBIT APIs are used to securely request, manage, and process user consent.

Financial Information (FI) Request Workflow

The FI Request Workflow outlines how a Financial Information User (FIU) requests data from Financial Information Providers (FIPs) via the Account Aggregator. Once consent is granted, the FIU can initiate a financial information request, and the AA retrieves the required data from the FIP. ReBIT APIs are integral in transmitting these requests securely and ensuring that only authorized data is shared with the FIU.

Router Integration Changes

The following sections provide a detailed explanation of these above mentioned workflows, including a diagram illustrating API interactions (Reference) within the AA ecosystem. The diagram also highlights changes related to the Router. Review these sections carefully to understand the modifications and the necessary updates to your code.

The Account Discovery & Linking process involves identifying the financial accounts a user holds across various institutions (FIPs) and linking them to the Account Aggregator for easy management and data access.

Steps Involved in Account Discovery & Linking:

1. User Login and Identity Verification:

The user logs into the AA application and provides their mobile number or other identity verification details. The AA then queries the FIPs to discover accounts associated with the user.

API (Internal API Spec): /user/send-otp (POST): The user login process after entering the phone number sends an OTP for login.

API (Internal API Spec): /user/verify-otp (POST): The user enters the OTP sent in the previous step to verify and login.

2. Request to FIPs for Account Discovery through Router:

The Account Discovery request is routed to the FIP via the Router, following these steps:

• Retrieve the FIP identifier from the Central Registry.

• Construct the request header (x-request-meta) using the retrieved identifier for Router compatibility.

• Transmit the request to the Router along with the prepared header.

Upon receiving the request, each FIP searches its records for accounts associated with the provided identity (e.g., mobile number or email).

ReBIT API: /Accounts/discover (POST) with 'x-request-meta' header: The FIP returns details about the user's accounts to the AA.

3. User Confirms Accounts to Link:

Once the AA receives the list of accounts from various FIPs, it presents this information to the user. The user selects the accounts they wish to link with the AA. To authorize the linking, the user receives a One-Time Password (OTP).

ReBIT API: /Accounts/link (POST) with 'x-request-meta' header: The AA sends a request to FIP through Router with request header (x-request-meta) to initiate linking of the account with the AA customer account.

ReBIT API: /Accounts/link/verify (POST) with 'x-request-meta' header: The user needs to provide the OTP sent with the previous step to complete the account linking. The AA send the OTP as token to FIP through Router with request header (x-request-meta) to verify the account link.

4. Accounts Linked Successfully:

After successful OTP verification, the user’s selected accounts are linked to the AA. The FIP will send a notification to the AA on successful OTP verification for the account linking. These accounts can now be used for data sharing in future consent workflows.

ReBIT API: /Account/link/Notification (POST) with 'x-request-meta' header: The FIP sends a notification about status of account linking to AA through Router. The AA confirms that the accounts have been successfully linked and communicates this to the user.

Reference Implementation Guide & Using Simulator

For the above use case implementation, AA need to implement a few internal APIs for hanlding the user registration, login and accounts data along with the ReBIT API Specification.

In this scenario, the AA need to have a mock FIP to support the integration testing with mock response for the API requests to FIP. Please use the "FIP-SIMULATOR" for the integration testing with mock data. Please refer to Testing with Simulator for more details.

The consent workflow is a fundamental part of the Account Aggregator (AA) ecosystem. It ensures that Financial Information Users (FIUs) can access user data from Financial Information Providers (FIPs) only after obtaining explicit consent from the user. This workflow is governed by a series of secure and standardized interactions using the ReBIT APIs.

Steps Involved in Consent Workflow:

Pre-requisites:

The Account Discovery & Linking is handled by the user to execute the Consent workflow.

1. FIU Initiates Consent Request through Router:

The FIU initiates the process by sending a consent request to the Account Aggregator (AA). The request specifies the type of financial data, the duration, and the purpose for which it is being requested. This consent request is made by the FIU to the AA through Router, following these steps:

• Retrieve the FIP identifier from the Central Registry.

• Construct the request header (x-request-meta) using the retrieved identifier for Router compatibility.

• Transmit the request to the Router along with the prepared header.

ReBIT API: /Consent (POST) with 'x-request-meta' header: The FIU sends the consent request to the AA using this API through Router. The request includes the data access requirements, purpose, and duration for which access is required.

API (AA Internal Spec): /Consent/create (POST): The AA create the consent artefact and stores for future use with pending status.

2. AA Presents Consent to User:

After receiving the consent request, the AA communicates with the user via its mobile app or web portal, presenting the consent details. The user reviews and either approves or denies the request.

API (AA Internal Spec): /Consent/read (GET): The AA retrieves the consent artefact details to present to the user for approval.

3. User Grants Consent:

If the user approves the consent request, the AA generates a consent artefact. This artefact is a formal document containing all the details of the user’s consent, such as the scope, purpose, and validity.

API (AA Internal Spec): /Consent/accept (POST): The AA update the status and stores the consent artefact after the user grants approval.

4. AA Shares Consent with FIU & FIP through Router:

Once consent is granted, the AA sends the consent artefact to both the FIU and the relevant FIP. The FIP uses this consent artefact to validate requests for financial data.

ReBIT API: /Consent/Notification (POST) with 'x-request-meta' header: The FIU & FIP is notified about the granted consent via this API. It helps,

• FIU to fetch the consent artefact from AA and use it for FI request.

• FIP to validate the future FI data requests from the FIU.

ReBIT API: /Consent/fetch (POST) with 'x-request-meta' header: The FIU fetches the Consent artefact from AA through Router to use it for future FI data requests.

5. Consent Revocation (Optional):

The user has the ability to revoke consent at any time, cutting off access to their data.

API (AA Internal Spec): /Consent/revoke (POST): This API allows the user to revoke previously granted consent.

Overview

SahamatiNet has developed Response Simulators for each type of entity in the AA ecosystem. These simulators replicate the behaviour of AA, FIU, or FIP while interacting with ReBIT APIs for Router integration, enabling seamless testing and validation.

By mimicking real Entity Protocol APIs, the Response Simulator provides a controlled environment where developers can test the router service independently without relying on a live entity.

The sample workflow diagram below illustrates the usage of the Response Simulator by including a simulated response with the expected response.

The following two details are required in the request to use the APIs with Response Simulator:

• recipient-id: This is specified in the x-request-meta header through which the router that will route the request to the respective response simulator.

  • Based on the respective use case you can use the following Entity ID as recipient-id, which are mapped to the respective Response Simulators in Sandbox environment,

    • AA-SIMULATOR

    • FIU-SIMULATOR and

    • FIP-SIMULATOR

• x-simulate-res: This header should contain a hint for the expected response from the response simulator. It can be any of the options listed in the specific entity tables. If this is not included, the response simulator will default to returning a 200 OK response.

Sample Request Headers:

x-request-meta: [Base64 of {"recipient-id": "AA-SIMULATOR"}]
x-simulate-res: DataGone

OTP Scenario:

The FIP's Accounts/link/verify API is the only one that utilizes the OTP received from the customer. This API is responsible for submitting the token/OTP back to the FIP to complete the account linkage process. The Response Simulator is set up to accept a predefined list of OTPs for successful account linkage. If an OTP outside of this list is used, the account linkage will fail. This is the default behavior of the Response Simulator, functioning without the need for the x-simulate-res header.

List of OTPs accepted by Response Simulator

The sample workflow diagram below illustrates the usage of the valid OTP

The sample workflow diagram below illustrates the usage of the invalid OTP

AA - Response Simulator:

This AA response simulator will support all the APIs listed under this ReBIT Spec - https://api.rebit.org.in/viewSpec/AA_2_1_0.yaml

Sample FI/fetch workflow using AA-SIMULATOR:

Preloaded Scenarios

The AA Response Simulator (AA-SIMULATOR) includes preloaded scenarios that can be accessed by sending the corresponding scenario ID in the x-scenario-id header. The table below lists the scenarios available from the AA Simulator.

This is to inform all participants of the Account Aggregator (AA) ecosystem about the deprecation of the ReBIT API V1 in the Central Registry and the necessary steps for transitioning to the V2 API.

Key Updates:

• Deprecation of ReBIT API V1: As per the notification from ReBIT on 12th May 2024, the ReBIT V1 API has been officially deprecated. All ecosystem participants, including FIPs, FIUs, and AAs, must complete their transition to the ReBIT V2 API by 30th June 2024.

• For Participants Using V1: You are required to update your API Endpoint URLs to V2 in the Central Registry. Please share your V2 endpoint details with the Sahamati Services team.

• For Participants Supporting Both V1 and V2: To ensure a smooth transition, it is recommended to deprecate the V1 endpoint URL by updating it to /v1/nonexistent-resource in the Central Registry. This will signal to users that the V1 endpoint is no longer valid, ensuring they switch to V2 seamlessly.

• Best Practices: As a best practice, participants should refresh the Entities Endpoint URL from the Central Registry daily. This ensures that any updates made by other participants transitioning to V2 are reflected in your system, helping avoid miscommunication or errors.

Implementation Timelines:

• The ReBIT V1 API deadline has already passed. Participants must ensure that their V1 API Base URLs are updated in the Central Registry to V2 to avoid disruptions.

Action Required:

• Update your Base URLs Please reach out to services@sahamati.org.in to update your application Endpoint Base URLs from V1 to V2 in the Central Registry.

The Financial Information (FI) Request Workflow allows a Financial Information User (FIU) to request data from a Financial Information Provider (FIP) via the Account Aggregator (AA), based on user consent.

Steps Involved in FI Request Workflow:

Pre-requisites:

The Account Discovery & Linking, Consent Workflow are handled by the user to execute the FI request.

1. FIU Sends FI Request to AA through Router:

After the user’s consent is obtained, the FIU sends a Financial Information (FI) request to the AA to retrieve the data from the relevant FIPs. This request contains the details of the data required (such as bank account statements, loan details, etc.).

ReBIT API: /FI/Request (POST) with 'x-request-meta' header: The FIU sends the FI request to the AA specifying the type of financial data required and the consent artefact through Router, following these steps:

• Retrieve the FIP identifier from the Central Registry.

• Construct the request header (x-request-meta) using the retrieved identifier for Router compatibility.

• Transmit the request to the Router along with the prepared header.

2. AA Forwards FI Request to FIP through Router:

The AA validates the request against the consent artefact and forwards it to the relevant FIP through Router. The FIP retrieves the requested data from its system.

ReBIT API: /FI/Request (POST) with 'x-request-meta' header: The AA forwards the FI request to the FIP, including the consent artefact and data requirements.

3. FIP Shares the Session Id with AA:

Upon receiving the request and validating it against the consent artefact, the FIP provides a session Id to use as reference to fetch the data once it is ready.

4. FIP sends a Notification to AA through Router:

FIP asyncronously compose the requested FI data and sends a notification to AA about the readiness to trigger the FI fetch request to get the data.

ReBIT API: /FI/Notification (POST) with 'x-request-meta' header: The FIP sends a notification to AA through Router once the FI data composed and available to fetch.

5. AA Fetches FI data from FIP & Sends a Notification to FIU through Router:

Once the AA receives the notification from the FIP, it fetches the financial information from the FIP through Router. This data is provided in the agreed format and scope as per the consent.

Once the FI data is ready, AA sends a notification to FIU about the readiness of FI data to fetch by FIU from AA.

ReBIT API: /FI/fetch (POST) with 'x-request-meta' header: The AA sends a FI fetch request to FIP through Router to receive the FI data for the specific Session Id.

ReBIT API: /FI/Notification (POST) with 'x-request-meta' header: The AA sends a notification to FIU through Router once the FI data available to fetch.

4. AA Delivers Data to FIU through Router:

Once the AA receives the data from the FIP, it delivers the financial information to the FIU. This data is provided in the agreed format and scope as per the consent.

ReBIT API: /FI/fetch (POST) with 'x-request-meta' header: The AA delivers the financial information to the FIU through Router based on the initial request.

5. FI Request Completion:

After the FIU receives the data, the FI request workflow is marked as complete. The FIU can now process the data in line with the consent provided by the user.

FIU Response Simulator

Preloaded Scenarios

The FIU Response Simulator (FIU-SIMULATOR) includes preloaded scenarios that can be accessed by sending the corresponding scenario ID in the x-scenario-id header. The table below lists the scenarios available from the FIU Simulator.

For the POC integration, there are two key validation steps to be completed:

1. Validation with Simulators: The first step involves validating your Application/APIs with the respective simulators based on your Entity Type. If you are an FIU, you will test the integration with the AA Simulator. If you are an AA, you will validate with both the FIU and FIP Simulators. If you are an FIP, you will validate with the AA Simulator. This ensures that all APIs are functioning correctly and the response codes align with the ReBIT Specification Response Codes.

2. Validation with REs: The second step occurs once other respective REs (Registered Entities) have onboarded and completed their validation with the simulators. You will then test your integration with these REs to ensure that your application works seamlessly with other participants in the ecosystem.

The Sahamati team will share the list of test cases for API testing based on the ReBIT specification. We will collaborate with you to evolve these test cases throughout the POC, refining and improving them to ensure they comprehensively cover all aspects of the integration and make the process more streamlined and effective.

In both of these validation steps, you are required to share the results with the Sahamati team as evidence to confirm that the integration meets the necessary standards.

More details on these validations will be provided as we progress through the POC.

AA Ecosystem Release Calendar by Sahamati

The Release Calendar outlines the updates and improvements introduced by Sahamati in the common services provided to the Account Aggregator (AA) ecosystem. It highlights key feature deployments and their scheduled timelines for both UAT and Production environments, enabling participants to stay aligned with regulatory and ecosystem-related enhancements. By adhering to the deployment dates, participants can seamlessly integrate these updates into their own release cycles, ensuring they stay up to date with the evolving changes.

2024 - Q4

For detailed information on the API changes, do refer to the API documentation link here

2024 - Q3

Update on Client Secret Rotation:

Based on the UAT feedback regarding client secret rotation, we will be updating the validity period for newly generated tokens to 180 days. As a result, the planned deployment, originally scheduled for 3rd October 2024, has been deployed on 16th October 2024, following the next round of UAT.

The next release will also include changes that allow entities to parameterise and configure the expiry period themselves, based on their respective regulatory guidelines.

This is to inform all participants in the Account Aggregator (AA) ecosystem about the new Client Secret Rotation policy, following the recommendations from market participants.

Key Updates

• Best Practice Recommendation: Following feedback from market participants, it was recommended that the Client Secret Token used for authentication of Token Service should be rotated periodically to enhance security and mitigate risks related to token misuse or compromise.

• Current Observations: A substantial number of participants have not rotated the Client Secret provided during their initial onboarding with the Central Registry (CR). To address this, Sahamati is introducing a Client Secret Rotation feature that enables participants to rotate their secrets efficiently and securely.

• Designated Authorised Users: Each participant organisation must designate an authorised user who will be responsible for managing the Client Secret rotation. This user will be onboarded into the Token Service (Identity & Access Management) and tasked with rotating the secret using new APIs. The SPOC (Single Point of Contact) must also ensure that the newly generated secret token is securely integrated into their organisation's systems. It is recommended to use a service account email associated with the participant organisation. This ensures the account remains under the organisation's control for long-term management, providing consistency and seamless operation over time.

• Secret Token Expiration: Moving forward, Client Secret Tokens set by Entities will expire every 180 days. All participants are required to rotate their Client Secrets before the expiration date to ensure uninterrupted access to the network. This regular rotation is essential to maintaining the security of the AA ecosystem.

Implementation Timelines

• UAT Environment: The Client Secret Rotation feature is now live in the UAT environment, allowing participants to begin testing the process immediately.

• Production Environment: The feature is now available in the Production environment post deployment on 16th October 2024.

Action Required

1. Onboard Your Designated User: Each participant must onboard a designated user to the Central Registry, ensuring they are responsible for secret rotations. You can share the designated user's details, along with your current entity information in the Central Registry, with services@sahamati.org.in.

2. Generate and Rotate Client Secrets: Once the designated user is onboarded by Sahamati, they will receive an email to set a password. Using this email and the newly set password, the designated user can generate a user token for the Token Service (IAM) through User Token Generate API. They can retrieve the existing secret using the Secret - Read API and reset it using the Secret - Reset API to generate a new client secret. The new secret should be rotated into your application. Please refer to the API documentation for further details.

3. Update Systems for Token Expiration: Ensure that your systems and applications are prepared to handle the periodic 180-day token expiration. Implement a token rotation mechanism using the new APIs to automate this process.

4. Manual Rotation Option: If automation is not yet ready, you can still rotate the token manually by directly calling Sahamati’s API.

Please ensure these changes are incorporated into your applications and processes by the given deadlines to maintain uninterrupted access to the AA ecosystem.

Update on Client Secret Rotation:

Based on feedback from UAT on client secret rotation, we have extended the validity period for newly generated tokens to 180 days. Consequently, the deployment, initially scheduled for 3rd October 2024, was completed on 16th October 2024.

Please note that there will be NO automatic expiration of existing secret tokens in the Central Registry. Entities must initiate and set the expiration themselves, using the process outlined above.

In the upcoming release, entities will also be able to parameterise and configure the expiry period of their secrets, in line with their specific regulatory guidelines.

FIP Response Simulator:

Preloaded Scenarios

The FIP Response Simulator (FIP-SIMULATOR) includes preloaded scenarios that can be accessed by sending the corresponding scenario ID in the x-scenario-id header. The table below lists the scenarios available from the FIP Simulator.

As part of Sahamati’s ongoing enhancements, the Central Registry APIs have transitioned to Version 2 (V2), following the ReBIT V2 standard. The V2 APIs upgrades done in Jan 2024 are aimed to improve the discovery of entities and streamline the retrieval of endpoints and certificates.

The v1 APIs of Central Registry had been deprecated since Jan 2024.

Key Update:

• Transition to V2 APIs: While most ecosystem participants have successfully migrated to the V2 APIs of Central Registry, some are still using the now deprecated V1 APIs. To enforce this transition, V1 APIs are scheduled for decommissioning with this release.

• Impact on V1 API Users: Starting from the decommissioning date, any requests made to the deprecated V1 APIs will return a 410 HTTP Status Code, indicating that the requested resource is no longer available and that users must switch to the V2 endpoint.

Implementation Timelines:

• UAT Environment: These changes have already been deployed in the UAT environment.

• Production Environment: The decommissioning will take effect in the Production environment post deployment in October 2024.

Action Required:

• For Participants Still Using V1 APIs: If you are among the participants still using the V1 API to access the Central Registry, you need to transition to the V2 APIs of Central Registry immediately. Any attempt to use the V1 version after decommissioning will result in a 410 HTTP response code.

• Update your application accordingly to ensure compatibility with the V2 APIs.

Member / Entity

• Definition: Refers to a Financial Information User (FIU), Financial Information Provider (FIP), or Account Aggregator (AA) within the Account Aggregator ecosystem and Sahamati Network.

SahamatiNet Router Overview

Q. What is the SahamatiNet Router, and what role does it play in the AA ecosystem?

• The SahamatiNet Router is a network service that streamlines and secures interactions between Financial Information Providers (FIPs), Account Aggregators (AAs), and Financial Information Users (FIUs). It simplifies communication by reducing integration complexity, ensuring interoperability, and enabling secure data exchange.

Q. How does the SahamatiNet Router enhance integration and collaboration within the AA Ecosystem?

• The Router provides a standardised network interface, eliminating the need for multiple custom integrations. It handles backend tasks like traffic routing and load balancing, simplifying data exchange and promoting better collaboration among participants in the AA ecosystem.

Q. How does the Router handle scalability as the AA ecosystem grows?

• The Router is designed for scalability and can manage increased traffic and participants as the ecosystem expands. It supports horizontal scaling, multiple availability zones, and multi-region cloud deployments, ensuring high performance and availability.

Q. How does observability in the SahamatiNet Router benefit participants?

• The Router offers real-time observability, allowing participants to monitor API call frequency, response times, and error rates. This enables optimised system performance, easier issue diagnosis, and improved operational efficiency.

Integration Process and Onboarding

Q. Is the additional onboarding process for FIUs, AAs, and FIPs still required by the AA Ecosystem application when integrating with the SahamatiNet Router?

• Once onboarded to the SahamatiNet Router, there is no additional onboarding required for FIUs, AAs, or FIPs in their respective applications. All participants will have already undergone the necessary compliance and validation through SahamatiNet, ensuring this step is covered for all entities. This process aligns with current participant interactions.

Q. Will this change impact the integration process?

• Yes, this change simplifies the integration process by eliminating the need for extra code or configuration for additional onboarding in your application. It enhances the ease of connection and overall efficiency across the AA ecosystem.

Technical Aspects

Q. Are there any data size limits or timeout considerations?

• Yes, there are defined data size limits and timeout rules outlined in the integration guidelines. These values will be finalised and standardised during the Proof Of Concept (POC), with a consensus process involving all participants.

Q. What about the delay in using the integration?

• The integration is designed to be sub-second, ensuring minimal delay. The Router ensures fast, efficient communication between entities, facilitating seamless interactions.

Testing and Compliance

Q. Is integration with SahamatiNet mandatory?

• No, integrating with SahamatiNet via the Router is not mandatory for participating in the AA ecosystem. However, integration simplifies interactions and ensures secure, standardised, and efficient communication between REs (Registered Entities).

• For example, if an AA gets onboarded to SahamatiNet, it gets access to all the onboarded FIPs without having to integrate individually with each FIP. Similarly, when an FIU gets onboarded to SahamatiNet, technically, it has access to all AAs who are onboarded. AA will still need the bilateral commercial agreement with the FIUs.

Q. What is the purpose of the SahamatiNet Router sandbox environment?

• The sandbox environment allows participants to test integrations in a risk-free setting that mimics real-world conditions. For the Proof of Concept (POC), the SahamatiNet Sandbox is used for validation and troubleshooting before transitioning to UAT and production environments.

• Note: The Sandbox environment is independent of the UAT and Production environments of SahamatiNet.

Base URLs for Each Environment

How To create or decide on an Entity ID value in the onboarding request ?

• An Entity ID is a unique identifier that represents a specific entity such as an FIU (Financial Information User), AA (Account Aggregator), or FIP (Financial Information Provider). It should follow a clear, readable naming convention that helps identify the entity.

• Best practice for naming Entity IDs: Use a suffix-based naming convention like:

  • For FIUs: XYZ_FIU

  • For AAs: ABC_AA

  • For FIPs: AXBYCZ_FIP

• For Lower environments you can even add the environment name as well

  • For FIU : XYZ_UAT_FIU or XYX_SANDBOX_FIU

  • For AA : ABC_UAT_AA or ABC_SANDBOX_AA

  • For FIP : AXBYCZ_UAT_FIP or AXBYCZ_SANDBOX_FIP

• Ensure that the Entity ID is a unique and easily recognisable name of the organisation that is getting onboarded. It can include letters, numbers, or symbols, but a simple and meaningful string is recommended.

• Do note, the above examples and recommendations use an underscore ( _ ) as the delimiter. You can also use hyphens ( - ) if preferred.

Steps for Onboarding to SahamatiNet Router in Sandbox:

1. What You Need to Provide:

• Organisation Details: For onboarding your organisation as an Entity (FIP, AA, or FIU) in the Central Registry.

  • Entity ID for your organisation

  • Base URL Endpoint to your application

  • RSA Public Key

  • IP Address, inbound and outbound ports [optional for UAT, required for Production environment for whitelisting]

• Designated User: Provide required contact details of a representative responsible for generating and managing the client secret key for your entity in IAM(Token Service).

  • Name, Email address of the designated email account from your organisation.

  • It is recommended to use a service account email associated with the participant organisation. This ensures the account remains under the organisation's control for long-term management, providing consistency and seamless operation over time.

2. Where to Find Onboarding Details:

3. Submission Process:

• For regulated entities in AA ecosystem, do send the required details to sandbox@sahamati.org.in.

• The Sahamati team will review your submission and provide access credentials to your designated user via an email.

• Do note, this step will be moved to a registration page on a self service portal for SahamatiNet Router going forward.

4. Client Secret Token Generation:

• Once the designated user is onboarded by Sahamati, they will receive an email to set a password.

• Using this email and the newly set password, the designated user can:

This section offers simple instructions for performing essential tasks within the Sahamati ecosystem. These guides aim to help participants easily navigate and complete key technical processes

• How To Onboard to Sandbox ?

• How To Decide on an Entity ID ?

• How To Create a Certificate ?

• How To Generate Tokens ?

How to generate and validate tokens using APIs (using curl)

To generate and validate access tokens from Sahamati, here are sample curl commands for User Token and Entity Token APIs. It is recommended to use Postman for quicker and more efficient testing. However, the following curl commands are helpful for direct implementation within code.

User Access Token API: This API generates a token for a user (email/password-based authentication). To generate a User Access Token, the user must provide their username (email) and the password configured during the account activation process. This access token is necessary for interacting with the member's secret management APIs. The access token has an expiry of 24 hrs.

Example curl

curl -X 'POST' \
  'https://api.sandbox.sahamati.org.in/iam/v1/user/token/generate' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'username=<your-email>&password=<your-password>

Entity Access Token API: This API generates a token for an entity based on its ID and secret. The generation of a Member (Entity) Access Token requires the ID (client ID) and the Secret. This access token is used for the interaction with other members. The access token has an expiry of 24 hrs.

Example curl

curl -X 'POST' \
  'https://api.sandbox.sahamati.org.in/iam/v1/entity/token/generate' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'id=<entityId>&secret=<entitySecret>'

Ensure you replace <your-email>, <your-password>, <entityId>, and <entitySecret> mentioned in above curl with actual values when running these commands.

Postman Collection: You can also download the Postman collection from the Sahamati developer portal. The Postman collection includes pre-configured API requests and is ideal for rapid testing and validation of token generation.