What problem are we trying to solve
As the AA ecosystem grows, it is essential to simplify, to the extent possible, the onboarding process of a new regulated entity (FIU, FIP or AA) becoming certified and ready to join the ecosystem.
The two major work streams for a participant, i.e. an FIU or a FIP, in the area of certification are:
The process of negotiating with certifiers directly could often become burdensome, given the need to deal with questions about:
- The necessity of this service
- The scope of this service
- A fair “cost” of the service
- Availability of choice of service providers
The process of getting the certificate involves technical tasks and interaction with the certifier. It also involves understanding the test cases of the framework and resolving doubts with either the certifier or with Sahamati on those.
This usually involves a few weeks worth of effort.
While it is important for us to reduce friction in the above areas, it is imperative for us to retain a key principle:
Assessment of conformance to ReBIT standards, through the independent empaneled certifiers, must be performed for every FIU, FIP or AA that wishes to be awarded a certificate.
Role of TSPs in providing a solution to the above
So, what role can TSPs play in designing a solution that meets the above requirements and constraints?
TSPs, offering software that conforms to the ReBIT technical standards, may choose to become intermediate certified entities. An Intermediate certified entity is one that is itself certified by one of the empaneled certifiers and is further qualified to offer a pre-negotiated certification service through the empaneled certifiers to end-entities, such as FIPs, FIUs or AAs.
Analogy with chain-of-trust in cryptography
In the world of digital certificates, a chain of trust functions with the same intent: to form a linked path of validation and verification from a trust anchor down to an end-entity certificate.
A chain of trust consists of several parts:
- A trust anchor, which is the originating certificate authority (CA).
- At least one intermediate certificate, serving as “insulation” between the CA and the end-entity certificate.
- The end-entity certificate, which is used to validate the identity of an entity such as a website, business, or person.
Similarly, the chain-of-trust to verify conformance to AA technical standards consists of:
- A trust anchor, which is one of the empaneled certifiers
- An intermediate certified entity, which is certified by the trust anchor and possesses an intermediate certificate of conformance, typically a TSP
- The end-certified entity, which is the FIP/FIU/AA, using the intermediate certified entity
TSPs as intermediate certified entities
Technology Service Providers, in the AA ecosystem, may choose to use any one of the empaneled certifiers to procure an “intermediate certified entity” certification.
Once certified, the TSP may offer the following services and benefits to participants, (i.e. FIUs, FIPs, AAs) that use its services:
As an intermediate certified entity, The TSP’s implementation of the AA Technical Standards is pre-validated by one of the empaneled certifiers
|Drastically reduces the time it takes for the entity seeking to be certified, to actually get their certification process done
|Pre-negotiated certification charges*|
Once certified, the TSP is qualified by the empaneled certifier to offer a pre-negotiated certification service to end entities
|No separate negotiation required between participants and the empaneled certifiers directly.
|Outsourced certification operations**||TSPs act as the point-of-contact on behalf of FIUs / FIPs and AAs, for all certification operations
|* Actual mechanics of invoicing and collection are left to the TSP and the empaneled certifier to determine.
** Actual mechanics of how the end-certified entity gets the certificate are left to the TSP and the empaneled certifier to determine
Yes, this is left to the TSP’s choice. However, the certificate awarded by one empaneled certifier cannot be deemed as valid by another certifier. The TSP has to be certified separately by each empaneled certifier it engages.
It does not as long as TSPs deploy a certified solution for on-prem and hosted (cloud) models. The standards do not distinguish between on-prem and hosted (cloud) deployment models. Neither does the certification framework.
It is up to the empaneled certifiers to define workflows that support intermediate certified entities in effectively offering operations support for getting end-entities (FIUs, FIPs, AAs) certified.
Yes. The primary goal of enabling TSPs to be deemed intermediate certified entities is for them to reduce the friction for end-entities in getting certified. Friction arises on two counts – commercial and operations.
Intermediate certified entities are expected to enable a reduction in friction on both counts.
Have more questions? Write to us at firstname.lastname@example.org.