Page Comparison

G2P bulk payments

Soban Najam

• Payment instructions are sent to the payments Building block but payment information is not supposed to be sent to the payments BB.

• One key component within the payments BB is the account mapper that can associate the beneficiary to their respective account at the FSP.

• The account information of the beneficiary can be obtained from the FSP either through the payment switch or the FSPs, however the payments BB need to be able to find a link between the beneficiary and the their account and a fundational ID would be used in this case since at onboarding by the FSP this is used.

@SasiKumar Use of a funcional ID for G2P payments.

• Wondered if the payments BB weather functional ID would be different for each of the different registrations, @Soban pointed out that the foundational ID would be different for each government programme.

• Every single provider will get a PSU token which will be given out by tthe ID buidling that has been authorised by the user.

• @SasiKumar pointed out that when a registration building block asks for a user's name, photograph, and other basic information, and requests permission to link the user's identity to a central payment switch or a bank. There is conset required from the user, If the user consents, the registration building block obtains an access token, which can be used to call APIs to authorize transactions on behalf of the user. The access token can be exchanged for a PSU token specific to the building block that invoked the registration building block, provided that the user's consent is valid and recorded in the ID building block. This mapping is done using a Token Introspection RFC 7662.

• A three-step process for making payments was proposed, The first step involves registering the beneficiary and issuing a functional ID or PSU token to them, The second step involves populating the beneficiary's payment destination details in the account mapper, and the third step is the actual payment itself.

• Mauree, Venkatesen suggested that an API be provided to the user so they can enter their account information, Soban expressed concern about allowing users to update the mapper directly.

• Soban suggests In the discussion, it was noted that the Foundational ID never leaves the ID BB and a PSU token which is equivalent to the Functional ID (which is a composite identification token comprising of the Foundational ID, Benefit Programme ID and the Government Entity ID) can be kept in the mapper to identify each eligible beneficiary of a Social Benefit programme. 

• It was noted that since the Foundational ID never leaves the ID BB it is problematic for obtaining the payment account information of the user from the FSP.

• Soban suggested obtaining the necessary information from the registration building block, which seems to be a separate component of the project. 

• However, it was pointed out that this step will happen  after registration, at the time when the eligibility of the person is confirmed by the Social Benefit BB.Mauree, Venkatesen  

• It was proposed by Vijay that at the time of the confirmation of the eligibility of the person, a notification could be sent by the Social Benefit BB which will request for consent of the user to keep their payment account information in the mapper and an Account Mapper API would be invoked when the user provides his/her consent so they can enter their account information. The person will need to be authenticated before giving their consent. The data provided by the user would be stored in tokenised form in the mapper.

• Vijay added that to ensure the accuracy of the data entered into the mapper and agrees , the payment account information will need to be verified. It was agreed that a validation process is would be a necessary step before storing the data in the mapperIt was also agreed that the registration interface needs updating to reflect the new approach..