|Purpose||To clarify the purpose of “Certification”|
|Description||“Certification” is essentially a technical guarantee of adherence to the open API specifications (published by ReBIT).
The Certification framework comprises three community-defined elements:
The benefit of being certified is that it provides a guarantee of “good behaviour” (technically) to other members of the community, thus generating trust amongst AA participants and citizens, reducing the count and cost of downstream errors and grievances.
The open test cases of the certification framework, much like the Central Registry, Token Service and legal Participation Terms – form part of a stack of Digital Commons designed and driven by the community. They are not part of RBI Master Directions or ReBIT Technical Specifications.
|Purpose||To clarify the frequency of re-certification required, if any|
|Description||The Certification Framework is based on a set of tests, which are aligned to a version of the open API specifications.
The first version of the Certification framework is aligned to V 1.1.2 of the ReBIT open API specifications.
Once certified for a particular version of the specifications, an entity need not be recertified so long as the entity is on the same version.
However, a periodic self-assessment and submission of reports to a certifier is expected to be conducted on a quarterly basis. This is to ensure that inadvertent errors have not crept in, owing to changes introduced in the application, post-certification
|Purpose||To clarify the role of empaneled certifiers|
|Description||The scope of the first version of the Certification Framework is limited to verifying API implementations.
The role of the empaneled certifiers for this version, has been to devise test automation solutions that allow an entity to perform two activities:
These test automation solutions (also known as Certification Toolkits) are usually offered for a price.
AA participants may negotiate prices with the empaneled certifiers directly or via their TSP (Technology Service Provider) partners.
As the ecosystem grows, the scope and mechanics of the certification framework has to grow in two directions:
*reducing barriers of cost and complexity for API certification
*enhancing scope of certification to include data governance audits
In this context, the role of empaneled certifiers will also undergo a transformation. The same is currently being discussed within the AA community.
|Purpose||To clarify the role of TSPs in the certification process|
|Description||TSP (Technology Service Providers) may get their solutions pre-certified via any of the empaneled certifiers and acquire the status of an “Intermediate Certified Entity”.
Such TSPs may then negotiate with empaneled certifiers, as resellers, to onboard FIUs onto their systems and get the FIUs certified through a one-time re-run of their systems, for each FIU.
The intent behind this is three-fold:
|Purpose||To clarify if a holding company can be certified on behalf of its subsidiary FIUs|
|Description||The intent of the certification framework is to ensure AA participants give the technical guarantee of their implementations adhering to the specifications.
A holding company that is not an FIU, cannot provide this guarantee on behalf of other companies, even there is a shareholding relationship amongst them.