Onboarding new nps on existing nps

[venkatramanm]

Introduction

While ondc is an open network. There are times participants need to onboard other participants onto their platform for security, settlement, kyc etc. This are typically due to auditing or operational requirements for the nps businesses .

Ondc data collection about the participants should have been sufficient to avoid this additional overhead but due to the minimal data collection policy of ondc, at times, it has been inadequate for several participants .

Some of the examples include:

1. Whitelisting ip addresses of participants so that DOS attacks can be averted.
2. Accounts information, pan and GST information for kyc and settlement.

The problem

Having to collect these information from each other manually diminishes the value of open networks and adds overheads to participate in open networks. For.e.g new Bpp after meeting all ondc requirements, still has to talk to multiple baps one by one so that their inventory is listed on that bap.

Proposal.

Nps host machine readable information about themselves needed for their auto onboarding to other counterparty nps.

This information needed will be arrived at by nps comming together and arriving at the minimal set of data required for on-boarding purposes.

Currently known information that is collected are ip addresses to whitelist, GST, pan and account information.

How will it be published ?

There are a few choices.

1. The data(format could be json or XML or html) can be hosted at an endpoint relative to the np's subscriber url. E.g /about.json
2. A protected /about api using usual signing protection

• This may not work asis because on_about would not reach the calling party if the ip of the server sending /on_about is not whitelisted.

3. Registry collects this url and sends it in lookup api.

Open for debate and discussion.

[venkatramanm]

The account information sent in on_init api at transaction level is an override. In case money goes to seller Directly in certain usecases. While this is possible in Beckn . Ondc may not want to do it for now as it complicates settlement and need for account validations with penny drop dynamically may create unwanted overhead.

[nitinmish]

Its a good idea. In an open network, KYC is definite requirement. Registry already carries the B[A,P]P ID and the /about could possibly be a relative URI, similar to what happens during subscribe call while . For example:

BPP ID: ONDC.xyz.com
/about: https://ondc.xyz.com/about

This API can also be spaced out along with a type attribute such as content-type or mime-type etc. Can we define a standard structure for it and publish?

[nitinmish]

@BLR-0118 @ravi-prakash-v

[VidyaGF]

@venkatramanm - Additionally, there may be documents required for verification and authenticity of seller NP, like GST docs and other documents, which are to be collected and verified. That wont be a limitation with API like /about ?

[venkatramanm]

Actually collecting these IDs from the data in about.json and checking outside the network should be possible.

[VidyaGF]

I agree you have a lot of APIs that verify the ids, but I am not sure if they can do that based on the data in about.json.I am still thinking from the perspective of regulatory compliance or preventing fraud, would that still be required? I will have to research online aggregators At present, does that still take the ID docs or do we have who goes only with the data?