This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.
Configuring the Open-Banking.xml File for UK
Configure open-banking.xml
files in both WSO2 Open Banking Key Manager(WSO2 OB KM
) and WSO2 Open Banking API Manager(WSO2 OB APIM
) components based on the configurations listed below.
The open-banking.xml files are in below locations:
<WSO2_OB_KM_HOME>/repository/conf/finance/open-banking.xml
<WSO2_OB_APIM_HOME>/repository/conf/finance/open-banking.xml
Do the following configurations in both the Key Manager and API Manager components and restart the servers.
Configuration | |||||||
---|---|---|---|---|---|---|---|
1 | Define the specification that you plan to deploy. Possible values: <DeployedSpecification>UK</DeployedSpecification> | ||||||
2 | If you want to enable the event notification feature, set the
<EventNotifications> <IsEnabled>false</IsEnabled> <TokenIssuer>www.openbank.com</TokenIssuer> <NotificationExpiryTime>180</NotificationExpiryTime> <NotificationAPIUrl>https://<WSO2_OB_APIM_HOST>:8243/open-banking/v3.1/event-notification</NotificationAPIUrl> </EventNotifications> | ||||||
3 | To log the Consent Management API calls in JSON format:
| ||||||
4 |
<MultiAuthorization> <DaysToExpireRequest>3</DaysToExpireRequest> </MultiAuthorization> | ||||||
5 |
<SharableAccountsRetrieveEndpoint>http://<WSO2_OB_APIM_HOST>:9763/open-banking/services/bankaccounts/bankaccountservice/sharable-accounts</SharableAccountsRetreiveEndpoint>
<PayableAccountsRetrieveEndpoint>http://<WSO2_OB_APIM_HOST>:9763/open-banking/services/bankaccounts/bankaccountservice/payable-accounts</PayableAccountsRetrieveEndpoint> In some banks, some PSUs may have a certain number of accounts, but not all accounts have the ability to be shared externally or to make a payment online. In a bank, the shareable account list and the payable account list can either be the same or different. In the default WSO2 Open Banking solution, at least two APIs are expected to return shareable and payable accounts when passing the user_id, and the given JSON response must be returned. Then it automatically loads the accounts list in the consent page. { "data": [ { "account_id": "1234-2345-3456-4567", "display_name": "1234-2345-3456-4567" }, { "account_id": "9999-4345-8456-4567", "display_name": "9999-4345-8456-4567" } ] } By default, mock backend deployed in http://<WSO2_OB_APIM_HOST>:9443/as400/payable-accounts/{userId} If you plan to implement the multi-authorization feature for the PISP flow, the payable account retrieval endpoint should return the following JSON response. { "data": [{ "account_id": "30080098971337", "display_name": "30080098971337", "authorizationMethod": "multiple", "authorizationUsers": [{ "customer_id": "123", "user_id": "psu1@wso2.com@carbon.super" }, { "customer_id": "456", "user_id": "psu2@wso2.com@carbon.super" } ] } ] }
http://<WSO2_OB_APIM_HOST>:9443/as400/sharable-accounts/{userId} | ||||||
6 | Enable Request-URI validation: This is available only as a WUM update and is effective from December 02, 2019 (12-02-2019). For more information on updating WSO2 Open Banking, see /wiki/spaces/updates/pages/16318500. During account retrieval to validate <!-- Validate AccountID with consented accountID in account retrieval --> <ValidateAccountIdOnRetrieval>true</ValidateAccountIdOnRetrieval> | ||||||
7 | Configure the role to identify the customer care officers, who are able to access the customer care portal, and revoke the consents on behalf of customers. <UK> <CustomerCareOfficerRole>Internal/CustomerCareOfficer</CustomerCareOfficerRole> </UK> | ||||||
8 | The unique ID of the ASPSP to which the request is issued. The unique ID is issued by OBIE and corresponds to the Organization ID of the ASPSP in the Open Banking Directory. If the value does not match the expected value (based on the Client ID or network certificate of the caller), the ASPSP must reject the request with a 403 (Not Authorized) status code. <UK> <XFAPIFinancialId>open-bank</XFAPIFinancialId> </UK> | ||||||
9 | According to the openbanking.org.uk specification, the links to access the created resource must be returned, as follows. "Links": { "Self": "https://api.alphabank.com/open-banking/v2.0/accounts/22289" }, In order to generate the self URL shown in the above JSON, configure the URLs of the exposed APIs, as shown in the below configuration. <UK> <PaymentAPIURL>https://<WSO2_OB_APIM_HOST>:8243/open-banking/{version}/pisp/</PaymentAPIURL> <AccountAPIURL>https://<WSO2_OB_APIM_HOST>:8243/open-banking/{version}/aisp/</AccountAPIURL> <FundsConfirmationAPIURL>https://APIM_HOSTNAME:8243/open-banking/{version}/cbpii/</FundsConfirmationAPIURL> <!--configure the url to get details about the error--> <ErrorURL></ErrorURL> </UK> | ||||||
10 | In order to improve the performance of the API Gateway, the consent validation responses for account information retrieval calls are cached.
<UK> <Cache> <EnableConsentValidationCache>true</EnableConsentValidationCache> <ConsentValidationCacheExpiry>900</ConsentValidationCacheExpiry> <DefaultCacheTimeout>120000</DefaultCacheTimeout> </Cache> </UK> | ||||||
11 | In the AISP flow, when the TPP invokes the account retrieval APIs, they can either use the /accounts/{consentId} or /accounts/{accountId}. If they want to use consentId, the <UK> <UseConsentIdInPath>false</UseConsentIdInPath> </UK> | ||||||
12 | The following configuration is used to handle release management of the deployed API specifications. E.g., If the resource is created using the API specification version v2.0, that resource can only be accessible using API specifications v2.0 and above. <UK200SupportedSpecsToRequest>UK200|UK300</UK200SupportedSpecsToRequest> <UK> <UK110SupportedSpecsToRequest>UK110|UK200|UK300</UK110SupportedSpecsToRequest> <UK200SupportedSpecsToRequest>UK200|UK300</UK200SupportedSpecsToRequest> <UK300SupportedSpecsToRequest>UK300</UK300SupportedSpecsToRequest> </UK> | ||||||
13 | Account permissions not supported by the ASPSP can be restricted for the TPP by specifying one or more permissions separated by a pipe (|). By default, no permissions are restricted. E.g. ReadOffers|ReadPAN|ReadParty|ReadPartyPSU <UK> <RestrictedPermissions></RestrictedPermissions> </UK> | ||||||
14 |
<UK> <DCR> <!--the supported authentication methods for the token endpoint --> <TokenAuthentication> <Method>private_key_jwt</Method> <Method>client_secret_basic</Method> </TokenAuthentication> <!--the connection and read time out values for retrieving the remote jwks to validate the ssa and request jwt signatures during tpp registration--> <ConnectionTimeout>0</ConnectionTimeout> <ReadTimeout>0</ReadTimeout> <!--The endpoint urls are to access the rest APIs of API manager in order to create the application, service provider and generate keys for the application. --> <EndPointURL> <ServiceProviderCreation>/client-registration/v0.14/register</ServiceProviderCreation> <Application>/api/am/store/v0.14/applications</Application> <Token>/token</Token> <KeyGeneration>/api/am/store/v0.14/applications/generate-keys</KeyGeneration> <ApiSearch>/api/am/store/v0.14/apis</ApiSearch> <ApiSubscribe>/api/am/store/v0.14/subscriptions/multiple</ApiSubscribe> </EndPointURL> <!--if true validate the policy,client,terms of service,logo uris --> <EnableURIValidation>false</EnableURIValidation> <APISubscriptions> <PISP> <APIContext>/open-banking/v3.1/pisp</APIContext> <APIContext>/open-banking/v3.0/pisp</APIContext> <APIContext>/open-banking/v2.0/pisp</APIContext> </PISP> <AISP> <APIContext>/open-banking/v3.1/aisp</APIContext> <APIContext>/open-banking/v3.0/aisp</APIContext> <APIContext>/open-banking/v2.0/aisp</APIContext> </AISP> </APISubscriptions> <!--if true validate the hostnames of policy,client,terms of service, logo uris match with the hostname of redirect uri--> <EnableHostNameValidation>false</EnableHostNameValidation> </DCR> </UK> | ||||||
15 |
<UK> <PaymentRestrictions> <MaximumInstructedAmount>1000.00</MaximumInstructedAmount> <!--Frequency patterns that are supported by the ASPSP can be configured as a regex pattern separated by a pipe (|). By default, ^(EvryDay)$|^(EvryWorkgDay)$|^(IntrvlWkDay:0[1-9]:0[1-7])$|^(WkInMnthDay:0[1-5]:0[1-7])$|^(IntrvlMnthDay:(0[1-6]|12|24):(-0[1-5]|0[1-9]|[12][0-9]|3[01]))$|^(QtrDay:(ENGLISH|SCOTTISH|RECEIVED))$ regex is supported. If you want to change the default pattern uncomment the following configuration and configure the regex pattern <PermittedFrequencyPattern></PermittedFrequencyPattern> before v1.3.0, there was a configuration to configure restricted frequency pattern. But it is now deprecated <RestrictedFrequencyPattern></RestrictedFrequencyPattern> --> <!--The allowed pattern for configuring the amount for domestic standing orders--> <!-- <AllowedAmountPattern></AllowedAmountPattern>--> <!--The allowed pattern for configuring the currency for domestic scheduled payments--> <!--<AllowedCurrencyPattern></AllowedCurrencyPattern>--> <MaximumFuturePaymentDays>90</MaximumFuturePaymentDays> ... </PaymentRestrictions> </UK> | ||||||
16 |
<UK> <PaymentRestrictions> <!-- Configurations regarding the handling of Payment requests after a cut off DateTime --> <CutOffDateTime> <!--IsEnabled denotes whether a CutOffDateTime is to be enforced by the ASPSP --> <Enabled>false</Enabled> <!--SelectedPolicy denotes the preferred Approach to handling requests past the CutOffDateTime. Allowed values are: 1. REJECT - Reject all requests arriving past the DateTime value 2. ACCEPT - Accept all requests arriving past the DateTime value and return ExpectedExecutionDateTime and ExpectedSettlementDateTime. --> <CutOffDateTimePolicy>REJECT</CutOffDateTimePolicy> <!--Expected format for all dates - hh:mm:ss.ffffff+|-hh:mm --> <!--The Daily time requests are to be cut off at --> <DailyCutOffTime>17:30:00+00:00</DailyCutOffTime> <!--Need to be set if the SelectedPolicy is set to ACCEPT. The ExpectedExecutionTime and the ExpectedSettlementTime for the next day --> <ExpectedExecutionTime>10:00:00+00:00</ExpectedExecutionTime> <ExpectedSettlementTime>11:00:00+00:00</ExpectedSettlementTime> </CutOffDateTime> </PaymentRestrictions> <UK> | ||||||
17 | The expiry time for the issuer certificate and the subjectDN of the sent transport certificate stored in cache. <UK> <CertificateValidationCacheExpiry>3600</CertificateValidationCacheExpiry> </UK> | ||||||
18 | In consent re-authentication of the accounts flow, during authorisation, the PSU is allowed to change the selected account. If the <UK> <ConsentReAuthentication> <EnableAccountUpdateByPSU>false</EnableAccountUpdateByPSU> </ConsentReAuthentication> </UK> | ||||||
19 | If Mutual Transport Layer Security (MTLS) is terminated before the request reaches the Gateway, retrieve the TPP's certificate from the MTLS session and include as a transport certificate header. By default, the gateway expects <CertificateManagement> <!-- In order to enable the client certificate validation feature (Certificate Expiry, Signature and Revocation validation during MTLS), the following module needs to be engaged under the "Global Engaged Modules" section in the axis2.xml file. <module ref="mtlscertvalidator"/> --> <!--Set the value of the transport certificate header sent in the request if MTLS is terminated before the gateway default value is ssl.client.auth.cert.X509--> <TransportCertificateHeader>ssl.client.auth.cert.X509</TransportCertificateHeader> </CertificateManagement> The load balancer should not allow the TPP to send its certificate as a transport certificate header that is configured in the If such header was found in the TPP’s request, it is mandatory to remove that header from the TPP’s request. This is applicable even when the MTLS session is not terminated at the load balancer. <TransportCertificateHeader> tag:<ClientTransportCertAsHeaderEnabled>true</ClientTransportCertAsHeaderEnabled> | ||||||
20 | In order to enable certificate revocation validation for API security, make sure that the following configurations are added under the server root element. <CertificateManagement> <!-- Expiry time for the cache (in seconds) for storing the validation result of the certificates--> <ClientCertificateCacheExpiry>3600</ClientCertificateCacheExpiry> <!-- Enable/Disable certificate OCSP and CRL validation. Default value has been set to true --> <CertificateRevocationValidationEnabled>true</CertificateRevocationValidationEnabled> </CertificateManagement> Under <CertificateRevocationValidationEnabled>, add the following configurations for:
This is available only as a WUM update and is effective from December 10, 2019 (12-10-2019). For more information on updating WSO2 Open Banking, see Updating WSO2 Products. <!-- Proxy server configuration to do TPP certificate revocation checks --> <CertificateRevocationProxy> <Enabled>false</Enabled> <ProxyHost>PROXY_HOSTNAME</ProxyHost> <ProxyPort>8080</ProxyPort> </CertificateRevocationProxy> <!--Manager class implementation responsible for verifying certificate revocation status--> <RevocationValidationManagerImplClass>com.wso2.finance.open.banking.gateway.common.mtls.cert.validation.service.CertRevocationValidationManagerImpl</RevocationValidationManagerImplClass> <!-- Retry count for validating certificate OCSP and CRL revocation status --> <CertificateRevocationValidationRetryCount>3</CertificateRevocationValidationRetryCount> <!-- List of issuer DNs whose issued certificates needs to be skipped from certificate revocation validation. e.g. <IssuerDN>CN=Test Pre-Production Issuing CA, O=Test, C=GB</IssuerDN> --> <RevocationValidationExcludedIssuers> </RevocationValidationExcludedIssuers> | ||||||
21 |
<UK> <SigningConfiguration> <!-- Enable Signing --> <Enable>true</Enable> <OBIE> <!-- Trusted Anchor Configuration openbanking.org.uk specific Trust Anchor definitions --> <TrustedAnchors> <!-- Trust Anchor used in signing JOSE --> <Signing>openbanking.org.uk</Signing> <!-- Multiple values supported with `|` delimiter IE - trustanchor.org|trustanchor.org.uk --> <Validation>openbanking.org.uk</Validation> </TrustedAnchors> <!-- OBIE Organization Id --> <OrganizationId>ABC1234</OrganizationId> </OBIE> <!-- Default Singing Algorithm is PS256, to support others uncomment line below --> <!--<Algorithm>RS256</Algorithm>--> <!-- The following specified APIs will be mandated for message signing. --> <MandatedAPIs> <APIContext>/open-banking/v3.0/event-notification/</APIContext> <APIContext>/open-banking/v3.0/pisp/</APIContext> <APIContext>/open-banking/v3.1/event-notification/</APIContext> <APIContext>/open-banking/v3.1/pisp/</APIContext> </MandatedAPIs> </SigningConfiguration> <UK>
This is available only as a WUM update and is effective from July 06, 2020 (07-06-2020). For more information on updating WSO2 Open Banking, see Updating WSO2 Products.
| ||||||
22 | Add the following configurations that specify the allowed signature algorithms in TPP requests. With this configuration, WSO2 Open Banking rejects the JWTs signed in algorithms that are not in the following list. If the configuration is not added, no validation occurs and any algorithm is passed through. Allowed values are;
<UK> <AllowedInboundSignatureAlgorithms> <Algorithm>PS256</Algorithm> </AllowedInboundSignatureAlgorithms> </UK> | ||||||
23 | By default, two factors (basic, and smsotp) are configured to engage when a TPP creates an application and generates keys. If you want to configure a different authentication factor as the second authentication factor, configure that authenticator as a federated authentication in <SCA> <IdpName>SMSAuthentication</IdpName> </SCA> | ||||||
24 | Determines whether or not ACR is enabled. <ACREnabled>false</ACREnabled> | ||||||
25 |
<OBIdentityRetriever> <!-- Server Key configuration used for singing purposes IE - message signing --> <Server> <!-- alias the certificate is under --> <SigningCertificateAlias>wso2carbon</SigningCertificateAlias> <!-- KID value for signing certificate --> <SigningCertificateKid>1234</SigningCertificateKid> </Server> <JWKS-Retriever> <SizeLimit>51200</SizeLimit> <ConnectionTimeout>2000</ConnectionTimeout> <ReadTimeout>2000</ReadTimeout> </JWKS-Retriever> <!-- Cache Configuration for Identity Retriever Cache --> <Cache> <ModifiedExpiryMinutes>15</ModifiedExpiryMinutes> <AccessedExpiryMinutes>15</AccessedExpiryMinutes> </Cache> </OBIdentityRetriever> | ||||||
26 | Debitor account validation checks the debitor account for the PSU in the initiation request.
<!-- Configuration to disable debtor account validation in payments --> <ValidateDebtorAccount>true</ValidateDebtorAccount> | ||||||
27 | ASPSP supports payment data permissions that give access to the TPP by specifying one or more permissions to access payment information, separated by a pipe(l). By default, create permission is granted. <DataPermission>Create</DataPermission> | ||||||
28 | This is for the Data Reporting feature, to enable data publishing set the <DataPublishing> <!-- Include all configurations related to Data publishing --> <!-- Enable data publishing in WSO2 Open Banking--> <Enabled>true</Enabled> <!-- Server URL of the remote BI server used to collect statistics. Must be specified in protocol://hostname:port/ format. --> <ServerURL>{tcp://<WSO2_OB_BI_HOST>:7612}</ServerURL> <!-- Administrator username to login to the BI server for data publishing. --> <Username>admin@wso2.com@carbon.super</Username> <!-- Administrator password to login to the BI server for data publishing. --> <Password>wso2123</Password> </DataPublishing> | ||||||
29 | To enable Transaction Risk Analysis, set the < <TRA> <!-- Include all configurations related to Transaction Risk Analysis --> <!-- Enable TRA in WSO2 Open Banking--> <IsEnabled>true</IsEnabled> <!-- following configurations are used to enable TRA for specific flows only--> <!-- Enable TRA for Payments--> <PaymentValidationEnabled>true</PaymentValidationEnabled> <!-- Enable TRA for Accounts--> <AccountValidationEnabled>true</AccountValidationEnabled> <!-- Configurations related to TRA Receivers--> <Receivers> <!-- Administrator username to login to the remote BI server. --> <Username>admin@wso2.com@carbon.super</Username> <!-- Administrator password to login to the remote BI server. --> <Password>wso2123</Password> <!-- Receiver URLs of the Siddhi Apps used to validate for TRA.--> <TRAAccountValidationURL>http://<WSO2_OB_BI_HOST>:8007/TRAAccountValidationApp/TRAValidationStream</TRAAccountValidationURL> <TRAPaymentValidationURL>http://<WSO2_OB_BI_HOST>:8007/TRAPaymentValidationApp/TRAValidationStream</TRAPaymentValidationURL> </Receivers> <TimePeriodOfRecurringPayment>90</TimePeriodOfRecurringPayment> <MaxFrequencyOfTransactionsWithoutSCA>5</MaxFrequencyOfTransactionsWithoutSCA> <TotalAmountLimitOfTransactionsWithoutSCA>100</TotalAmountLimitOfTransactionsWithoutSCA> <LastSCATimeLimit>90</LastSCATimeLimit> <TransactionAmountLimit>30</TransactionAmountLimit> <!-- Number of maximum days of transaction history that can be accessed with the first-time consent use for Berlin.--> <FirstAccessHistoryLimit>90</FirstAccessHistoryLimit> </TRA> | ||||||
30 | You can enable the Fraud Detection feature by setting the < <FraudDetection> <!-- Include all configurations related to Fraud Detection --> <!-- Enable FD in WSO2 Open Banking--> <IsEnabled>true</IsEnabled> <!-- Configurations related to FD Receivers--> <Receivers> <!-- Administrator username to login to the remote BI server. --> <Username>admin@wso2.com@carbon.super</Username> <!-- Administrator password to login to the remote BI server. --> <Password>wso2123</Password> <!-- Receiver URLs of the Siddhi Apps used to validate for FD.--> <FraudDetectionURL>http://<WSO2_OB_BI_HOST>:8007/FraudDetectionApp/FraudDetectionStream</FraudDetectionURL> <InvalidSubmissionURL>http://<WSO2_OB_BI_HOST>:8006/InvalidSubmissionsApp/InvalidSubmissionsStream</InvalidSubmissionURL> </Receivers> </FraudDetection> | ||||||
31 | By default, the Consent Management APIs are secured with basic authentication. To access the Consent Management APIs, use the default user or create a new user using the Key Manager Management Console.
For more information, see configuring basic authentication for Consent Management APIs. | ||||||
32 | Configure the client certificate header name in the <CertificateManagement> <!--Mutual TLS Authenticator Certificate header--> <ClientAuthenticationHeader>x-wso2-mutual-auth-cert</ClientAuthenticationHeader> </CertificateManagement> | ||||||
33 | To enforce regulatory certificates for API invocations, add the following configuration under the This is available only as a WUM update and is effective from April 26, 2021 (04-26-2021). For more information on updating WSO2 Open Banking, see Updating WSO2 Products. <EnforceRegulatoryCertificates>true</EnforceRegulatoryCertificates> |