Overview

Connect your Application to our Production Environment

Before you connect your App into our production environment we have to ensure you meet our security baseline requirements. These requirements ensure we meet our obligations as a regulated financial institution and help give other regulated financial institutions comfort that you can do the same.

We’ll commit to keeping these standards up to date to ensure everyone stays compliant.

You’ll be required to attest to meeting these requirements annually.

Minimum Security Requirements

Requirement	Description	Additional Details
Encryption key management	Ensure effective key management is implemented to protect client data.	Verify that your app meets these requirements for OAuth token management. OAuth tokens or customer-identifying information must not be exposed within your app or shared with other parties. Token management once a user completes the OAuth 2.0 authorization workflow: * Encrypt access_tokens and client_secrets which you store
Encryption in transit	Ensure that sensitive client data in your app is protected during the transport process.	(MANDATORY) Your App server is configured to support only TLS version 1.1 or higher. All requests to our environment are TLS version 1.2 or higher. (RECOMMENDED) Your App server is configured to support TLS version 1.2 using AES 256 or higher with SHA-256. Web application endpoints that receive sensitive customer information and/or authentication tokens in URL parameters must not return content via an HTTP Response Body and you must implement a 302 Found redirect for these requests. This is to prevent sensitive customer information from being accidentally leaked to 3rd parties in the subsequent HTTP Referrer request headers.
Authentication	Ensure that users who access your app are authenticated.	Ensure that strong customer authentication is enabled (minimum two step authentication or single sign on).
Indirect access to data	Ensure that unauthorised third-parties are unable to access customer data.	Third party access to customer data must be clearly stated within applicable policies and/or terms and conditions, and have a justifiable business need. Note: Third party access may include access via an external API, or through data that is stored. “Justifiable business need” may include (but not limited to) the utilisation of third party services, which is functionally required. For example, the use of third party biometric services.
App server configuration	Ensure that your app server is secure.	Ensure your server’s configuration follows industry accepted hardening practice for example: National Institute of Standards and Technology – Guide to General Server Security Relevant vendor recommendations
Vulnerability management	Ensure that your app is secure against the common vulnerabilities.	Follow an industry accepted standard for secure code development such as OWASP Top 10 to protect against vulnerabilities such as: Cross Site Request Forgery Cross Site Scripting (including reflected and stored cross site scripting) SQL Injection XML Injection Authentication, Sessions Management and Functional level access control (if any) Forwards or Redirects in use have been validated - All app session cookies have the following attributes set: Secure and HTTPOnly
Encryption at rest	Ensure that sensitive client data in your app is protected while at rest.	Encryption at rest using NIST Cryptographic Mechanisms is mandatory for data repositories that hold or manage sensitive commercial or personal information. Examples may include; full-disk, container, application or database level encryption techniques. We define sensitive commercial or personal information as information which if disclosed could cause harm to the individual or organisation. Examples include: Personal - date of birth, tax file number, address, income, biometric, credit history etc. Commercial - financial, transactions, accounts, trade secrets etc.
Audit logging	Ensure appropriate audit logging functionality is implemented and maintained.	Audit logging should include both application level (access logs) and event based actions. You should consider your environment and what logging should be implemented and ensure that the logging records include the following where applicable: Date and time of the event Relevant user or process Event description Success or failure of the event Event source e.g. application name ICT equipment location and identification Audit logs must be retained for as long as appropriate to enable future investigation. In most cases logs should be kept for a minimum of one year. Logs must be immutable and secure.
Data hosting	Ensure client data is not hosted in high risk areas.	Consideration needs to be given to country, legal, contractual, access, sovereignty and counter-party risks.
Security monitoring practices and breach reporting	Ensure you have security monitoring practices in place to detect and manage threats.	You need to be able to demonstrate that you scan your environment for threats and that you take appropriate action where you detect anomalies. Monitoring can be at the: network / infrastructure, application or transaction (data) layer. Where anomalies are detected you must report these to the DSP, providing enough information to enable further monitoring and/or preventative action.