Change Request: PISP Extensions to the Open API

[mjbrichards]

Open API for FSP Interoperability - Change Request

Table of Contents

• 1. Preface
  • 1.1 Change Request Information
  • 1.2 Document Version Information
• 2. Problem Description
  • 2.1 Background
  • 2.2 Current Behaviour
  • 2.3 Requested Behaviour
• 3 Proposed Solution Options

1. Preface

___

This section contains basic information regarding the change request.

1.1 Change Request Information

| Requested By | Michael Richards, ModusBox | | Change Request Status | In review ☒ / Approved ☐ / Rejected ☐ | | Approved/Rejected Date | |

1.2 Document Version Information

Version	Date	Author	Change Description
1.0	2020-05-19	Michael Richards	Initial version.

2. Problem Description

___ The extension of the Mojaloop product to accommodate PISPs (Payment Initiation Service Providers) requires new API resources, as well as some changes to existing resources. The question is whether these should be accommodated using the existing Open API specification, or whether it would be better to accommodate the new resources in a different API, and perhaps include PISP-specific versions of the existing Open API calls which PISPs would be allowed to use in the same API.

2.1 Background

The Mojaloop product is being extended to allow PISPs to become participants in Mojaloop schemes. Although PISPs do not have direct control of accounts, they are allowed, subject to the consent of the account owners, to ask the DFSPs who control the accounts to move funds out of those accounts, subject to confirmation by the account holders. The system is expected to be extended in the future to include additional functions, such as the ability to request an account balance or to ask for a statement, or to retrieve an account's KYC status.

It is expected that this process will consist of two separate phases. In the first phase, the PISP will contact the account-holding institution and request access to an account on behalf of a client. The account-holding insitution will satisfy itself that its customer really has granted permission to the PISP; and, subject to that, it will register the PISP as allowed to make requests to debit the customer's account(s).

The resources required to support this phase are:

Outbound:

1. GET /parties, to return the accounts associated with the customer's identifier
2. POST /consentRequests, to request permission to link with a customer's account(s)
3. GET /consentRequests, to enquire after the statur of a linking request.

Inbound:

1. PUT /parties, to receive information about a customer's accounts.
2. PUT /consentRequests, to receive confirmation that a linking request has been accepted for processing or rejected.
3. PUT /consents, to receive information about the final determination of a linking request

In the second phase, the PISP will request an actual transfer. The DFSP will request a quotation, and will then return the result to the PISP, and ask the PISP to obtain consent to the transfer from its customer. On receipt of the confirmation, the DFSP will action the transfer.

The resources required for this phase are:

Outbound:

1. GET /parties, to identify the DFSP of the payee
2. POST /thirdPartyRequests, to request a payment (assuming different resource name from the current /transactionRequests)
3. GET /thirdPartyRequests, ,to enquire after the status of a transaction request.
4. PUT /authorizations, to respond with a customer's confirmation to go ahead with a transfer.
5. GET /transfers, to enquire after the status of a transfer.

Inbound:

1. PUT /parties, to return the DFSP who owns a payee account.
2. PUT /thirdPartyRequests, to receive the status of a transfer request.
3. POST /authorizations, to receive a request from a DFSP for customer consent to a proposed transfer.
4. PUT /transfers, to receive information about whether a transfer has completed successfully or not.

2.2 Current Behaviour

/consentRequests, /consents and /thirdPartyRequests are new resources which do not exist at present. /parties and authorizations are resources which already exist, but for which changes are proposed as part of PISP development. /transfers is an existing resource to which no changes are proposed as part of PISP development.

3. Proposed Solution Options

___

This is an open question for discussion. No solutions are proposed at present.