Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

PISP Journey Based on Open Banking UK

50 views

Published on

A PISP (Payment Initiation Service Provider) is a regulated actor under PSD2 who has been granted permission to request consent from a consumer to connect to their bank account and initiate payments or transfers on their behalf. Open Banking API specifications support Payment Initiation Services (PIS)
that enable a PISP to initiate a payment order, with the PSU's explicit consent, from their online payment account held at their ASPSP. The PISP is then further able to retrieve the status of a payment order.
This deck covers the different payment types, API resources, the PISP Flow, multi authorization, cut-off date time, payment restrictions, integrating with the bank backend, and release management.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

PISP Journey Based on Open Banking UK

  1. 1. PISP Journey Based On Open Banking UK Charitha Deshapriya Senior Software Engineer WSO2 Open Banking Team
  2. 2. Agenda ● Introduction to PISP ● Different Payment Types ● API Resources ● PISP Flow ● Multi Authorization ● Idempotency Key Validation ● JWS Signature Validation ● Cut-off Date Time ● Payment Restrictions ● Integrating with the Bank Backend ● Release Management
  3. 3. Introduction to PISP ● Establish a bridge between the merchant and online banking platform of the payer’s account in order to initiate a credit transfer. ● Regulated actor under PSD2 ● Needs PSU’s explicit consent before providing payment services.
  4. 4. Improved User Experience with PSD2 Before PSD2 After PSD2
  5. 5. Payment Types ● Domestic Payments ● Domestic Scheduled Payments ● Domestic Standing Orders ● International Payments ● International Scheduled Payments ● International Standing Orders ● File Payments
  6. 6. Domestic Payments ● An instruction to ASPSP to make a one-off payment for a specific amount to a specific payee. ● payment schemes ○ Single Immediate Payment (SIP) via Faster Payments ○ BACS ○ CHAPS
  7. 7. Domestic Scheduled Payments PSUs can setup, through PISPs, an instruction to their ASPSPs to make a one-off payment ● For a specific amount ● To a specific payee ● On a specific future date.
  8. 8. Domestic Standing Orders PSUs can setup, through PISPs, an instruction to their ASPSPs to make a series of payments ● Of a specific amount ● To a specific payee ● On a number of specified future dates ● Or on a regular basis.
  9. 9. International Payments ● PSUs can initiate, through PISPs, single international payments from their GBP or foreign currency payment accounts. ● Payments can be made in any currency and to any country
  10. 10. International Scheduled Payments PSUs can setup, through PISPs, an instruction to their ASPSPs to make a one-off payment ● For a specific amount ● To a specific foreign payee account ● On a specific future date.
  11. 11. International Standing Orders PSUs can setup, through PISPs, an instruction to their ASPSPs to make a series of payments ● Of a specific amount ● To a specific foreign payee account ● On a number of specified future dates ● Or on a regular basis.
  12. 12. File Payments ● Allow PSU to make multiple payments from their payment accounts. ● Two type of Payments ○ Bulk payments ○ Batch payments
  13. 13. Payment API Resources ● Payment-Order Consent ○ POST /{Payment-Consent-Type} ○ GET /{Payment-Consent-Type}/{ConsentId} ● Payment-Order Resource ○ POST /{Payment-Type} ○ GET /{Payment-Type}/{PaymentId} ● In file payments there are additional resources. ○ POST /file-payment-consents/{ConsentId}/file ○ GET /file-payment-consents/{ConsentId}/file ○ GET /file-payments/{FilePaymentId}/report-file ● Funds Confirmation End Point for payments in UK Spec version 3.1.0
  14. 14. PISP Flow
  15. 15. Multi Authorization ● Joint Accounts where payments are to be authorized by multiple parties ● Any number of parties for authorization is allowed. ● Applicable to ○ Domestic Payments ○ Domestic Scheduled Payments ○ Domestic Standing Orders ○ International Payments ○ International Scheduled Payments ○ International Standing Orders
  16. 16. PISP Third party provider ASPSP Financial Institute / bank PSU A Initial authorizer PSU B Final authorizer Request Payment Order ConsumedPayment Id Multi Auth Status Awaiting Further Authorization Authorization Flow Authorize Consent AuthorizationAuthorization Code Event Notification Multi Auth Status Authorized Initiation Request Payment Consent Awaiting AuthorizationConsent Id Authorization Flow Authorize Consent AuthorizationAuthorization Code
  17. 17. Multi Authorization API EndPoint Description Method /{consentId}/status Returns Multiple Authorization status for ConsentId, this can be used to poll the status of an ongoing multiple authorisation session by the core banking system. GET /{consentId}/users Returns Multiple Authorization users for ConsentId, allowing to see user status for multiple authorization session. GET /{consentId}/ Returns Multiple Authorization for ConsentId. GET /{consentId}/ Initiate Multiple Authorization session. POST /{consentId}/{userId}/ Update user Authorization status of a consent. PUT
  18. 18. Idempotency Key Validation ● Payment initiation request and Payment submission and payment file upload requests contain x-idempotency-key Header. ● For payment initiation resource, and payment file resource WSO2 OB solution evaluates the Idempotency check. ● For payment submission resource , bank backend has to carry out this validation.
  19. 19. JWS Signature Validation ● The signature is provided in a custom header x-jws-signature ● To support non-repudiation ● Signed with TPP’s private key ● Response signed by an ASPSP’s private key ● Validation and response signing is done by a handler in APIM gateway
  20. 20. Cut-off Date Time Validation ● An ASPSP may return the specific CutOffDateTime when responding to a payment-order consent request. ● Two strategies for handling behaviour ○ Reject the payment-order ○ Accept the payment-order ■ If the policy is set to ACCEPT, the expected execution time for the next day may be populated by ASPSP ■ If the policy is set to ACCEPT, the expected settlement time for the next day may be populated by ASPSP
  21. 21. Payment Restrictions ● The standard does not impose any restriction ● Each ASPSP must determine appropriate restrictions ○ The maximum InstructedAmount allowable ○ The domestic-standing-order Frequency patterns supported ○ The maximum future date on a scheduled-payment ● In case a payment order consent violates any of these restrictions ASPSP must reject the the request
  22. 22. Payment Restrictions Configuration Can be configured in open-banking.xml file <PaymentRestrictions> <MaximumInstructedAmount>1000.00</MaximumInstructedAmount> <MaximumFuturePaymentDays>90</MaximumFuturePaymentDays> <CutOffDateTime> <Enabled>false</Enabled> <CutOffDateTimePolicy>REJECT</CutOffDateTimePolicy> <DailyCutOffTime>17:30:00+00:00</DailyCutOffTime> <ExpectedExecutionTime>10:00:00+00:00</ExpectedExecutionTime> <ExpectedSettlementTime>11:00:00+00:00</ExpectedSettlementTime> </CutOffDateTime> </PaymentRestrictions>
  23. 23. Bank Backend Integration
  24. 24. Bank Backend Integration Mainly the following APIs of core banking system need to integrated with WSO2 Open banking solution in order to support PISP flow. ● Payment Submission APIs ● Payment Retrieval APIs ● Payable Accounts API Multi-Authorization API of WSO2 OB Solution to allows bank backend to request multi authorization related information
  25. 25. Bank Backend Integration Configuration Payment Dynamic Endpoint Insequence Open-Banking.xml <filter source="$ctx:AM_KEY_TYPE" regex="PRODUCTION"> <then> <header name="To" value="https://localhost:9443/open-banking/services/payments/paymentservice"/> </then> <else> <header name="To" value="https://localhost:9443/open-banking/services/payments/paymentservice"/> </else> </filter> <PayableAccountsRetriveEndpoint>http://APIM_HOSTNAME:9763/open-banking/services/ba nkaccounts/bankaccountservice/payable-accounts</PayableAccountsRetriveEndpoint>
  26. 26. Custom Headers/Payloads Some custom headers used to carry information when calling payment APIs of bank backend. ● Account-ID Header Base64 encoded debtor account ID Sent in all the payment types except batch payments ● File Payload Base64 encoded payment file Sent in file payment submission payload
  27. 27. Release Management Payment-Order Consent ● POST ○ PISP is not allowed to create payment-order consent in one version and payment-order resource in a different version. ● GET ○ PISP is not allowed to access payment-order consent created in a newer version, via a previous version endpoint. ○ ASPSP has the option to allow PIPS or not to access Consent created in a older version, via a new version endpoint. In our solution it is allowed.
  28. 28. Release Management Payment-Order Resource ● POST ○ PISP is not allowed to use a consent from a previous version to create Payment Order in a newer version, and vice versa. ● GET ○ PISP is not allowed to access payment-order resource created in a newer version, via a previous version endpoint. ○ PISP is allowed to access the payment-order resource created in a previous version on a newer version endpoint
  29. 29. Release Management Configuration Available in open-banking.xml <UK110SupportedSpecsToRequest>UK110|UK200|UK300</UK110SupportedSpecsToRequest> <UK200SupportedSpecsToRequest>UK200|UK300</UK200SupportedSpecsToRequest> <UK300SupportedSpecsToRequest>UK300</UK300SupportedSpecsToRequest>
  30. 30. Additional Resources More Information http://wso2.com/solutions/financial/open-banking/ Documentation https://docs.wso2.com/display/OB130/WSO2+Open+Banking Try out WSO2 Open Banking https://openbanking.wso2.com Get in Touch openbankingdemo@wso2.com Solution RoadMap Open Banking and PSD2: Are your APIs ready for external testing? Meeting the March 2019 PSD2 Compliance Deadline with WSO2 Open Banking
  31. 31. THANK YOU wso2.com

×