The Account Aggregator (AA) ecosystem is live as of 28th December, 2020. As a leading financial institution you may already be a part of this ecosystem, or evaluating your entry strategy, perhaps through a TSP (Technology Service Provider).
This first guidebook is designed to provide you with an exhaustive overview of the FIP and FIU software modules, and help you select and review your TSP to get the best out of the AA ecosystem.
A nascent ecosystem has many unknowns. Over the next few weeks, we will demystify the ecosystem so that you have actionable insights of the opportunities it creates and the steps you need to take to maximise your competitive advantage.
1. Technical specifications
3. Use cases
5. Support & application monitoring
8. Customer support
ReBIT, the technology arm of RBI, has provided technical specifications to the AA ecosystem which, in the initial few months/years, might undergo frequent changes as the system evolves into a version of the framework that is most effective.
To minimize the impact of changing tech specs of the framework on your business, the following technical aspects are to be ensured:
1. The FIP/FIU implementation’s build, release and testing processes must be automated to better adapt to ever-changing specifications. The architecture of your FIP/FIU module should ensure ease of extensibility to adapt to a growing ecosystem with minimum effort.
2. There should be no changes in the code, but merely in the configuration, as and when new FI types are provided by the data principal or FIP.
3. Repetitive data fetch should be automated by your TSP without the need to make changes in the implementation of your end-use application.
4. Customer actions to consent requests must ring notifications in the system.
5. An SLA (Service-Level Agreement) must be adhered to for quick addition of new FI types from existing FIPs, or easy addition of new FIP categories when approved by regulators without putting extensive pressure on your engineering bandwidth.
There are currently 4 banks, 2 NBFCs and 3 AAs certified and live in the AA ecosystem. As per RBI guidelines and REBIT specifications, your FIP/FIU module must be 100% interoperable with all ecosystem players and should be extendable to other upcoming AA frameworks, ideally without any additional effort from you. Your implementation needs to interact with multiple FIPs, FIUs and AAs to serve all possible data requests and cater to all preferences of your customers. It becomes vital to ensure that the communication and flow of information between these entities are smooth and dependable.
1. Your TSP should have tested your FIP/FIU implementation with all certified banks, NBFCs and AAs for interoperability.
2. Your FIU module must seamlessly integrate with any Account Aggregator of your customer’s choice. This should ideally be achieved with an effort of 2-3 days.
As the AA ecosystem gives you access to increasing volume of authentic, consented and granular data, you will want to innovate experiences rapidly on behalf of your customers. To enable rapid innovation at scale, the following requirements are almost axiomatic:
1. Your FIU module must be flexible. There should not be any requirement for code change to adapt to AA for existing use cases.
2. Your FIU module should allow for easy integration with the end-to-end user journey. The FIU architecture and implementation should ensure minimal change to your applications to consume data from the AA ecosystem.
3. Getting new data for your new use cases should just be a configuration change on your FIU module and there should not be a requirement for any change in the code.
4. Your user journey should be seamless and it should not impose a break in journey to access another app or page within the ecosystem.
The AA ecosystem holds the potential to do what UPI did to digital payments, and bring that exponential scale to data. As more participants enter the ecosystem, more use cases get implemented, the usage of the framework will only increase manifold. With time, your FIP/FIU should be scalable to handle the increasing volume.
1. Your FIP/FIU module should be capable of handling high volume and still ensure that the SLAs are adhered to.
2. Testing of your FIP/FIU module for high volume should be performed at regular intervals by your TSP.
3. Your FIP/FIU modules should be capable of optimization in scale, going up and down depending on the volume of data and use cases and ensuring that the infrastructure cost is kept low.
4. Your FIP/FIU modules should be set up to be available with 99.9% up-time.
5. Your FIU module should effortlessly handle the complexity of ingesting data from multiple FIP sources with differing data density, frequency, size, and availability, leaving you to focus on the end use case.
As goes with any infrastructure installation & integration, a well-defined support and application monitoring process is needed to ensure continual smooth operations.
1. Your FIP / FIU module must have a comprehensive admin panel to view and download reports. Basic reports are necessary to monitor the service and ensure its availability, as well as automate future regulatory reporting.
2. The admin panel must have an RBAC (Role-Based Access Control) control.
3. Your FIP/FIU implementation should be monitored and configured for automatic alerts on occurrence of any abnormal activities or incidents.
4. Your TSP should design and implement health-check and housekeeping of your FIP/FIU module.
One cannot underestimate the importance of security when implementing systems of such scale and importance. The regulatory requirements of data protection mandates implementation of highly secure systems which are fail safe and hack proof.
1. Your TSP must be ISO-27001 certified.
2. Physical security:
a. A background check for TSP employees having access to systems should be performed.
b. Procedures should be established, and supporting business processes and technical measures implemented, for the use of encryption protocols for protection of sensitive data in storage, data in use (memory), and data in transmission.
a. MFA must be enabled for all access, and all access should be logged and audited.
4. Application Security:
a. The API provided should adhere to OWASP rules.
b. The role matrix or RBAC must be defined.
c. The certification process must be done quarterly or more frequently and it should be automated to have zero or minimal human interaction.
5. Process Security:
a. Your TSP should have a robust change management process and version control mechanism implemented. The years of experience in the software development life cycle of your TSP are important to ensure discipline and control over the development and maintenance of your FIP/FIU framework. Absence of process for change management may lead to unauthorized changes.
6. Cyber Security:
a. A secure code review and VAPT have to be conducted on your FIP/FIU implementation. Security is not just the job of a third-party certifying agency; it is a culture that your TSP has to build and practice at all levels of development and deployment.
b. Regular compliance audits should be ensured. Quarterly internal audits and regular external audits have to be built in the organization culture of your TSP.
c. The audit logs must be stored securely and managed to ensure availability.
a. Your data must be segregated and isolated.
b. The data purge & governance policy must be defined.
c. You must verify that the customer transaction data is deleted from your FIP/FIU module. As per the FIP specification, the data retrieved from the FI should be purged from the temporary storage immediately after it is delivered or, if not, it should be purged as per the ReBIT specifications. The FIU should use the data for the consented purpose until the consented duration only.
d. You should check if your customer’s PII data will be encrypted and stored. Your FIP/FIU module should not store more than the required PII data. The only PII data that is required is the mobile number or a unique customer identifier for identification.
e. No additional data other than mobile number or customer identifier, consent artefact and audit data need to be stored by the TSP module.
Any unforeseen circumstance may bring down the systems to halt without any prior notice. This situation should not halt your business. To ensure that, your FIP/FIU module should implement fail-proof BCP and DR processes and test the process to ensure continuity.
1. There should be a BCP-DR plan which must be tested frequently. The DR plan must cover multiple locations.
2. Incident management procedures need to be defined.
The AA ecosystem deals with your customer’s data. In case of any problem that may arise within your FIP/FIU implementation, you should be in a position to address the concern quickly and ensure that your core business is not hampered due to this.
1. Your TSP should have a dedicated customer success team to take care of your queries and address your concerns. You must make sure that you have an experienced team available to you whenever you need.
2. Your TSP should define a clear escalation process and matrix to ensure timely resolution of your concerns; you should know where to go if your concern is not resolved in a reasonable time.
3. You should set up a process for customer support and grievance redressal.
4. You should have an RBAC admin portal to look at all customer actions.
This guidebook is designed to be a map of the terrain when you are stepping into a new era of open banking systems, offering more transparency and control to the data principal. It will provide more opportunities to grow for the industry as a unified enabling force with enhanced customer experience and user journey at its core.
We would be delighted to engage more deeply with your teams in workshops, demos, etc. to address your specific questions.
Look out for future editions of this newsletter covering the following critical topics
1. Use cases - getting the best from your TSP
2. The business case for driving AA adoption
3. Driving AA adoption
4. Introducing Anumati
5. Data governance – are you ready for PDP
6. Introducing Perfios NewCo