Guideline No. CF001
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:

  • An open (i.e non-proprietary) suite of test cases, complementing the open API specifications – designed by the community
  • A set of third-party certifiers, empaneled by Sahamati
  • A set of rules governing the process of certification

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.
Stage Finalised
Guideline No. CF002
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
Stage Finalised
Guideline No. CF004
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:

  • To enable AA participants to deal with the TSP as their SPOC, for the entire AA implementation – and avoid the commercial and operational overheads of having to deal with the empaneled certifiers directly
  • To encourage TSPs to become force-multipliers for the AA ecosystem, by enabling them to be the SPOC for all technical, legal and even commercial aspects
  • To ensure the coverage of certification expands and is not limited to the reach of a small set of empaneled certifiers
Stage Finalised
Guideline No. CF005
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.
Stage Finalised

Back to AA Community Guidelines Summary