About this service
This service provides third-party providers (TPPs) access to payment initiation and information on behalf of SMBC Group's payment service users (PSUs). Within the sandbox environment, SMBC Group makes available simulated datasets.
To use this service, the TPP will first:
- use the token service to obtain a TPP access token;
- use this TPP access token via the consents service to create a consents resource and receive a redirect;
- (sandbox only) use the token service to request an authorisation code via a dedicated authorisation service, exclusive to the sandbox;
- (production only) redirect the PSU to perform strong customer authentication (SCA) against the Bank's online web portal, receive an authorisation code and be redirected back to the TPP with the authorisation code; and
- provide the returned authorisation code to the token service to obtain a PSU access token and a PSU refresh token.
Digital signatures
Requests to create, approve, and delete payments require digital signatures defined by the Cavage specification. The mandatory signing headers for each request are:
Creating payments
(request-target)- e.g."POST /berlingroup/v1/payments/pain.001-sepa-credit-transfers"consent-idx-request-iddigestpsu-id
Approving payments
(request-target)- e.g."POST /berlingroup/v1/payments/pain.001-sepa-credit-transfers/GP20220914000001/authorisations"consent-idx-request-iddigestpsu-idtpp-redirect-uripsu-ip-addresspsu-device-id
Delete payments
(request-target)- e.g."DELETE /berlingroup/v1/payments/pain.001-sepa-credit-transfers/GP20220914000001"consent-idx-request-iddigest
Pain.001.001.03 XML Schema Requirements
The following payment-product are supported:
pain.001-sepa-credit-transferspain.001-internal-transferspain.001-swift-transferspain.001-chaps-paymentspain.001-faster-payments
The request body must contain a valid pain.001.001.03 according to the schema requirements for each payment-product. SMBC Group uses SWIFT MyStandards to present our latest schemas. TPPs may access our XS2A MyStandards Readiness Portal. The portal defines SMBC Group's specific pain.001 restrictions per payment-product and provides a validation testing tool which identifies schematic and business validation failures.
Payment value date and expiration
- The TPP must provide a valid date in the Requested Execution Date () element. If the date provided is in the past, or if the request is received after cut-off, then the value date of the payment will be automatically amended to the next business day.
- Payments are automatically cancelled if they are not fully authorised within 90 days.
- Payments with a value date of more than 90 days in the past can only be viewed using a one-off consent resource. For further information, see the Consent Resource API Description.
Payment statuses
The status of a payment restricts what actions a user can perform to it. The following actions and restrictions are in use:
- PATC
- This is the first status of a newly created payment
- The status implies that the payment requires further authorisation from one or more users
- Whilst in this status, a user can view, authorise, and cancel the payment
- A user cannot authorise a payment in this status if another user has started an authorisation. The restriction will remain until the authorisation attempt is:
- successfully finalised by the user
- cancelled by the user
- timed-out after 5 minutes
- PDNG
- This status implies that the payment has been fully authorised and is now being processed by the bank
- Payments with a future value date may remain in this status until nearer the value date
- Whilst in this status, a user can only view the payment. A user cannot further authorise or cancel the payment
- RJCT
- This status implies that the payment has been cancelled
- The reason for cancellation is given in the status response
- Payments can become cancelled by:
- The user/TPP requesting DELETE /paymentId
- The payment expiring before becoming fully authorised
- The bank cancelling the payment during processing (a reason code will be provided)
- Whilst in this status, a user can only view the payment. A user cannot further authorise or cancel the payment
- ACCP
- This status implies that the payment has been processed by the Bank
- This is the final status of a processed payment
- The status does not imply receipt of funds at the beneficiary Bank
- The status response will advise the expected settlement date which may be later than the requested execution date
- Whilst in this status, a user can only view the payment. A user cannot further authorise or cancel the payment
Payment approval requirements
In alignment with the Bank’s payment service user interface, payments initiated via the XS2A API channel must meet authorisation requirements before they are processed.
- Number of required authorisations
- Every payment requires a minimum of one payment authorisation, which can be performed by creating a Payment Authorisation or by creating a Signing Basket.
- Some payments require a second payment authorisation, which can be performed by creating a Payment Authorisation or by creating a Signing Basket. The second authorisation is independent of the first and may use Payment Authorisation or a Signing Basket regardless of how the first authorisation was performed. A Signing Basket is for one PSU to perform one authorisation and then it is complete. The second PSU creates and completes their own Signing Basket which may contain any combination of payments they are eligible to authorise.
- Whether a payment requires one authorisation or two depends on the corporate customer’s preference. Payments that have a sum value greater than the corporate customer’s single approval limit will require a second authorisation. The corporate customers decide two limits, one for SEPA Bulk and one for Wire Transfers. A SEPA Bulk is a pain.001-sepa-credit-transfer that has at least one Payment (PmtInf) that contains at least two Credit Transfer Transactions (CdtTrfTxnInf), and a Wire Transfer is every other type of payment.
- The second authorisation cannot be performed by the PSU that performed the first authorisation.
- Two attempts to authorise a payment (whether through Payment Authorisation or Signing Basket) cannot be made simultaneously. The earliest request must be completed, cancelled, or timed out (after 5 minutes) before the next authorisation attempt can be made.
- Separation of duty
- A PSU that created a payment cannot perform the first authorisation of the payment. A second PSU must perform the first authorisation. Should a second authorisation be required, the PSU that created the payment can perform the second authorisation or a third PSU can perform the second authorisation.
- Signatory types
- Corporate customers may enforce signatory rules where their PSUs are sorted into two groups. Some PSUs are type A and some PSUs are type B. For these corporate customer’s, any PSU can perform the first authorisation but, if a payment requires a second authorisation, only a PSU in the other group can perform it. Payments can be authorised in the following combinations:
- A payment requiring one authorisation can be authorised by a PSU in group A.
- A payment requiring one authorisation can be authorised by a PSU in group B.
- A payment requiring two authorisations can be authorised by a PSU in group A followed by a PSU in group B.
- A payment requiring two authorisations can be authorised by a PSU in group B followed by a PSU in group A.
- Corporate customers may enforce signatory rules where their PSUs are sorted into two groups. Some PSUs are type A and some PSUs are type B. For these corporate customer’s, any PSU can perform the first authorisation but, if a payment requires a second authorisation, only a PSU in the other group can perform it. Payments can be authorised in the following combinations:
- Approval limits
- Corporate customers may enforce approval limits for their PSUs.
- An approval limit can be set for SEPA Bulk and be set for Wire Transfer. A SEPA Bulk is a pain.001-sepa-credit-transfer that has at least one Payment (PmtInf) that contains at least two Credit Transfer Transactions (CdtTrfTxnInf), and a Wire Transfer is every other type of payment.
- A PSU cannot authorise a payment if its sum value is greater than their approval limit. Another PSU with a greater limit must perform the authorisation instead.
- Approval limits are checked against each payment. A PSU can authorise multiple payments using a Signing Basket where each payment is not greater than their limit. The sum of the Signing Basket is not considered and may exceed their limit.
- Example 1: a PSU with a Wire Transfer approval limit of EUR 1000 cannot authorise a Wire Transfer payment of value EUR 1200
- Example 2: a PSU with a SEPA Bulk approval limit of EUR 1000 cannot authorise a SEPA Bulk payment which contains two credit transfers each with a value of EUR 600 because the sum value is greater than EUR 1000.
- Example 3: a PSU with a Wire Transfer approval limit of EUR 1000 and a SEPA Bulk approval limit of EUR 1000 can approve a Signing Basket that contains two Wire Transfers each of value EUR 1000, and two SEPA Bulks, each of sum value EUR 1000.