|Purpose||To clarify the mapping between FIU use cases and the purpose codes to be used, for each “Type” of use case|
|Description||As of V 1.1.2 of the specification, there are 5 purpose codes defined in the specification. The mapping between these and “types” of use cases is as follows:
101 – Wealth Management – to be used by SEBI RIAs and Stock Brokers (and similar licensees) seeking consent for data that enables them to facilitate investment transactions, either on a one-time or recurring basis
102 – Customer spending patterns, budget or other reportings – to be used by SEBI RIAs, PFRDA Retirement Advisors (and similar licensees) seeking consent for data that enables financial advisory use cases, typically on a recurring basis
103 – Aggregated Statement – to be used by lenders, insurers, insurance brokers (and similar licensees) seeking consent for data that enables underwriting and/or verification of income, typically one-time
104 – Explicit consent for monitoring of the accounts – to be used by lenders (and similar licensees) seeking consent for data enabling continuous monitoring of accounts to assess repayment health, typically on a recurring basis
105 – Explicit one-time consent for accounts – to be used by stock brokers (and similar licensees) seeking consent for data enabling verifying the presence and activity of a financial account, while onboarding users or modifying user profiles, typically on a one-time basis
Note: The above descriptions are indicative. If new use cases are discovered, the most appropriate purpose code is expected to be used, based on judgement and aligned with the descriptions above, to the best extent possible.
|Purpose||To clarify whether displaying the balance and transaction history of a single account is a valid use case under purpose code 102|
|Description||Purpose code 102 refers to “customer spending patterns, budget or other reportings” under the category “Personal Finance”.
The implicit expectation is that some degree of “analysis” on top of the raw data (i.e. balance, transactions) is being offered by an FIU.
Therefore, a “use case” of just a display of the balance, profile and/or transaction history is not a valid implementation of this purpose code.
However, an aggregation of balances across accounts (at a minimum), to provide a consolidated view across accounts is indeed a valid implementation.
A drill-down feature, that allows the consolidated view to be broken into balance/profile/transaction histories of individual accounts, is a valid implementation.
|Purpose||To clarify whether regular monitoring of accounts for purposes of a prospective financial service offer is a valid use case under purpose code 104|
|Description||Purpose code 104 refers to “explicit consent for monitoring of the accounts” under the category “Account query and monitoring”.
A “prospective” offer – refers to an offer to be made in the future.
If a financial services institution wishes to seek citizen’s consent for periodic monitoring of accounts, with the intent of profiling the financial position on a continuous basis and providing suitable financial offers in the future, the same may be done under this purpose code.
|Purpose||To clarify if multiple financial services can be tied to one purpose and one consent artefact|
|Description||The intent behind the concept of “purpose-limitation” is to ensure that there is a one-to-one mapping between the citizen’s understanding of the financial service h/she is interested in availing of, and the organisation’s usage of the data shared.
If a financial service involves the opening of multiple accounts as part of a single “Transaction” (e.g. often opening of a loan account also involves opening of a deposit account simultaneously), the “purpose” is deemed to be the same. In such a situation, the citizen is aware that the data shared will be used for opening of both accounts – since that is conjoined.
However, the converse – where data is taking for one specific financial service but used, additionally or in its place, for another financial service that the citizen is not explicitly seeking – is not good practice.
|Purpose||To clarify if the “purpose text” can be used by an FIU to provide specific, contextual information to the citizen, in place of the generic “purpose code” description provided for in the specifications|
|Description||The intent behind the design of the electronic consent artefact is to allow citizens to have clear and explicit knowledge of what their consent is being taken for.
The purpose description (against each purpose code) mentioned in the specifications is meant to be an overarching guide as to what the code means. This is meant to enable FIUs to use the appropriate code in their consent requests.
However, citizens would need specific, contextual information (such as a loan application number or a brand name of a financial product, e.g) as the real “purpose” for which they are being asked their date.
The purpose text field can therefore be used by FIUs to provide such rich, contextual information subject to community-designed limits and guardrails (e.g. no PII to be shared, character limits to be enforced).
Further, such information should NOT be part of the copy of the consent artefact sent by AAs to the citizen’s FIPs.
The FIP, is by design, as per current specifications, blind as to which FIU a citizen wishes to share her data with. Hence, context information input by the FIU in the consent request should not be visible to the FIP.
AAs have to implement this in their design.