Guideline No. AC001
Purpose To clarify the definition of an “AA Client”
Description ReBIT guidelines define an “AA Client” as possessing the following characteristics: 

  • An application that enables citizens to interact with the AA for the purposes of registration, account discovery and linking and consent management – thus implying that the “interface” (e.g. a screen) used by the citizen during the interaction is considered part of the AA Client.
  • Available as either a web application or a mobile application or a library that can be embedded in other web or mobile applications (subject to constraints imposed by security concerns)
  • Owned by an AA

The term “library” is interchangeable with the term “SDK”.

Further, as mentioned in the first characteristic, the “library” (or “SDK”) includes the customer-facing interface (such as a “Screen”).

A “set of APIs” or a “headless library” (i.e. without screens) does not qualify to be called an AA Client. These are internal engineering assets of an AA, which may be provided to their partner FIUs on the basis of bilateral agreements, for the purpose of co-development of an AA client.

Stage Finalised
Guideline No. AC002
Purpose To clarify ownership vs co-development aspects between an FIU and an AA, of an AA Client
Description An AA Client is necessarily owned by an AA. 

However, the interfaces (e.g. screens) that are part of the AA Client design may be customised or co-designed by FIUs, in partnership with AAs, to suit their user interface and user experience requirements.

The co-development scope may include any or all of the following:

  • User interface redesign
  • User experience (i.e. workflow or sequence of steps that a user experiences) redesign
  • Development assistance, supporting the redesign efforts

As long as the interaction is bound by common guidelines derived from Master Directions and/or technical specifications, FIUs and AAs are free to redesign AA Client interfaces as per their requirements.

Such common guidelines are codified in a community-driven “Customer Experience Guidelines Checklist”.

Further, any redesigned interface screens are also “owned” by the AA, with respect to all aspects of development and devops. As part of a joint design and development effort with respect to the interface screens, AAs may provide access to internal APIs as they deem fit, while retaining complete control over all aspects of development, testing and distribution.

FIUs and AAs are, however, free to enter into any bilateral legal agreements to restrict usage of such co-designed interfaces to named parties mutually agreed to.

Stage Finalised
Guideline No. AC003
Purpose To clarify if a single AA library can connect to multiple AA services
Description An AA library is a form of AA Client. An AA Client, as specified by ReBIT, is necessarily owned by an AA. 

While it is possible for one AA to partner with other AAs and provide an AA library that works with multiple AA services, it is not necessary for AAs to do so.

Further, given that AA libraries have to be owned by AAs, a “super library” owned by a TSP in partnership with AAs is also not feasible.

FIUs therefore, as of now, have to integrate AA libraries from different AAs, if they wish to connect to different AA services using the “library” mode of integration.

One possibility is for AAs to come together to co-own a single library that connects to their services.

This has to be further discussed within the community.

Stage Under Deliberation
Guideline No. AC004
Purpose To clarify the modes of integration available for an FIU to integrate its front-end application with that of an AA
Description An FIU may integrate its front-end applications using any of the following modes: 

For web apps of an FIU:

  • Redirection to a web application of an AA

The redirection may result in the web application of the AA being rendered either standalone or as an iFrame, within the parent web application.

For mobile apps of an FIU:

  • Redirection to a web application of an AA
  • Invocation of an embedded mobile library of an AA
  • App-to-app integration, with an pre-installed mobile application of the AA on the same device

Technical guidelines for Redirection have been Finalised within the community.

Technical guidelines for Invocation and app-to-app integration are being discussed within the community.

Stage Under deliberation
Guideline No. AC005
Purpose To clarify if an embedded Web Library is an acceptable form of an AA client
Description Embedded Web libraries (e.g. those built using Javascript) pose a serious data privacy risk. 

Applications that embed such web libraries, in their web applications, are likely to gain control over data that flows to-and-fro between the library and the backend service.

Such risks can be mitigated technically for mobile libraries (e.g. built using Android, iOS) embedded within host mobile applications. They cannot be mitigated for web libraries.

It is therefore recommended that no AA offers an embedded web library to FIUs as an AA client.

Stage Finalised
Guideline No. AC006
Purpose To clarify what “ownership” of an AA Client implies
Description An AA Client is necessarily “owned” by an AA. 

This implies the following:

For AA clients of type = web application:

  • Ownership of the application code and its underlying infrastructure (including the environment the application is hosted on) has to reside with the AA

For AA clients of type = mobile application OR mobile library:

  • Ownership of the application code, distribution of the applications, ownership of the distributed app packages has to reside with the AA

The accountability of all aspects pertaining to the AA client rests solely with the AA.

Stage Finalised
Guideline No. AC007
Purpose To clarify what metadata, if any, can be communicated between an AA client and the FIU app
Description The technical guidelines for Redirection and Mobile library invocation/ app-to-app integration provide clarity around what parameters can be passed back-and-forth between the FIU app and the AA client. 

In addition to parameters that help an AA authenticate the app user (e.g. mobile number) and the FIU determine user experience post-AA-interaction (e.g. whether the user approved a consent request or not), it may be useful for an FIU to determine the termination stage in a user’s AA journey.

This is useful for the FIU to provide appropriate support for repeat tries / grievance redressal to the citizen.

In addition to such information pertinent to an individual citizen’s AA journey, it would also be useful for the FIU to get anonymized, aggregated metadata about its customers’ AA journey. Such metadata may include all information necessary for the FIU and the AA to jointly construct a “drop-off funnel” and use the same to improve user experience.

The parameters that constitute such “metadata” – both for an individual citizen and at an aggregated, anonymized level – are being discussed within the community.

Stage Under Deliberation
Guideline No. AC008
Purpose To clarify branding guidelines for co-designed AA Client screens
Description All AA Client screens that are co-designed with FIUs ought to include a “Powered by <AA Name>” in a clearly visible area of the screen. The AA Logo may be optionally added, next to the AA Name. 

The FIU name and logo may also be optionally added to such co-designed screens, to ensure there is contextual continuity to users while switching between the FIU and the AA interfaces.

Stage Finalised
Guideline No. AC009
Purpose To clarify if the FIU name and logo can be displayed on AA Client screens in a redirection type of integration
Description AA Client screens may, optionally, show the FIU name and/or logo, from-and-to which the citizen will be redirected. 

This is to enable contextual continuity to users while switching between the FIU and AA interfaces.

Stage Finalised
Guideline No. AC010
Purpose To clarify if names of FIPs and logos are available for FIUs/AAs to display to citizens
Description FIUs are encouraged to design user journeys in which citizens can verify if their data custodian (FIP) is already part of the AA network or not. 

In order to do so, FIUs may get FIP names via the Central Registry API.

FIP logos are currently not part of the Central Registry. The same is being discussed currently.

Stage Under deliberation
Guideline No. AC011
Purpose To clarify if constraints (such as “count of accounts”) limiting the data to be collected, can be communicated by FIU through a redirection parameter
Description The consent request attributes allow an FIU to specify which FI Types the FIU would like consent for. However, there are use cases where the FIU would like to state the “count of accounts” (e.g. “1 savings account only”) that it wishes to seek consent for. 

The redirection and invocation guidelines may include this as an additional parameter. The same is being discussed within the community.

Stage Under Deliberation

Back to AA Community Guidelines Summary