Akahu’s purpose is to give people control of their data. We want to work with reputable third party developers who deliver on that purpose through their products.

Our accreditation process is designed to assess whether you meet our minimum standards for the protection of consumer data, and whether your product adds real value to consumers. We aim to strike a balance between getting you up and running quickly, while also ensuring that we’re supporting products that deliver great consumer experiences.

While developing your Akahu integration, we place sandbox restrictions on your app. Before you can release your Akahu integration for public/production use, your application must be accredited by Akahu. After successful completion of the accreditation process, we will issue a production environment that does not have any sandbox restrictions.

App risk tiers

The table below describes the risk tiers that we apply to different Akahu functionality. These risk tiers dictate our accreditation requirements.

---

Accreditation requirements

Each tier inherits requirements from all previous tiers.

Tier 0

Accept our terms of service (you do this automatically when creating a personal app).

Tier 1

You sign a contract to use the relevant Akahu services.

We carry out background due diligence.

We review your privacy notice to check that it covers any data exchange that is facilitated by Akahu.

We carry out a limited app review to check that Akahu-related functionality has been implemented appropriately. See the app review section below for more details.

Tier 2

We carry out a full app review. See the app review section below for more details.

Tier 3

We require a manual penetration test, or certification of current compliance with a relevant information security standard like SOC 2 or ISO 27001.

If you decide to meet this requirement with a manual penetration test, you will need to provide Akahu with a recent, relevant, and competent security and penetration test. The minimum scope of this testing should include grey box penetration testing of the user-facing application and any associated APIs. We also strongly encourage testing beyond that scope, including back office or administrative tooling, and security review of cloud infrastructure.

If you commission testing for the sole purpose of Akahu accreditation (i.e. you have no pre-existing testing results that meet our criteria), please commission the testing after your Akahu integration is complete.

---

App review

Tier 1 apps - limited app review

For tier 1 apps, we carry out a limited app review to check that Akahu-related functionality has been implemented appropriately.

Tier 2 and tier 3 apps - full app review

If you have developed a tier 2 or tier 3 app, Akahu will review your implementation to ensure that it complies with our security, authentication, and consumer control requirements as outlined in the section below. We recommend that you familiarise yourself with our requirements in the early stages of development to ensure that your accreditation is not delayed.

Requesting an app review

Once your application is production-ready, you will need to provide Akahu with access so we can carry out this app review process. You can provide access to either a staging environment, or a production environment with Akahu functionality enabled only for selected testing users.

We require access to a copy of your application on each platform that you are releasing on. For instance, if you are releasing a mobile app, we require both Android and iOS copies of your app. You will need to provide us with the following (dependent on platform):

• iOS: A TestFlight invite or AppStore link
• Android: An APK download link
• Web: A publicly accessible URL

Please also include any additional instructions that our testers might need to get signed in and use your application.

Before beginning this process, please first verify that you have signed a contract to use the relevant Akahu services, and that your app meets all requirements outlined below. Once complete, you can get in contact with our team at [email protected] to begin the process.

📘

Application review policy and fees

Successful completion of the Application Review stage is not an official endorsement by Akahu of your application's security posture or compliance with our requirements. As the application developer, it is your responsibility to ensure that your application is secure and compliant.

Akahu does not charge a fee for your first application review, or to check your fixes for any findings from your first application review. If subsequent application reviews are required, Akahu charges a fee of $1,000 per review.

All requirements are ongoing for the duration of your accreditation. You must notify Akahu in the event that you make changes that affect compliance with these requirements, at which point we reserve the right to reassess your accreditation status.

---

Requirements

Consumer information page

We want to ensure that consumers are well informed when making decisions about whether to grant access to their financial accounts.

We require a dedicated page or section on your website or app to explain how your product will use financial account access to provide value to consumers, and to explain the relationship with Akahu. We recommend inserting this page just before consumers are directed to Akahu's hosted connection flow.

Describe how you will interact with connected accounts

Describe how consumers will benefit from granting access to their financial accounts. If you have other purposes for collecting data, describe them to help consumers make an informed decision.

Example: Connect your bank account, and we'll automatically fetch your transactions.

Describe the scope of the access that you're requesting, and whether the duration that you're requesting is one-off or ongoing.

Example: We'll start by getting 12 months of transaction data, and then fetch updates daily until you tell us to stop.

Example: We'll automatically pay any bills that you mark as "approved for payment" in the app. We'll initiate payment for any approved bill up to the value of $2,000. Your payment authority can be cancelled at any time in the settings panel.

Relationship with Akahu

Include an accurate description of Akahu and a clear Akahu logo.

Example: Akahu is New Zealand's open finance platform. We use Akahu to fetch transaction data from your connected bank account. Find out more about Akahu here.

Akahu logo files can be found here.

Security

You must ensure that any data exchanged via Akahu or held in your systems are processed and stored securely. Below are the minimum standards that we expect:

• All traffic to/from the client is encrypted with strong SSL encryption.
• Akahu credentials (your App Secret and User Access Tokens) are not exposed to the client.
• User authentication meets the minimum requirements listed below.
• A secure OAuth implementation with appropriate use of state parameter (more info).
• All relevant risks identified in the OWASP Top 10 list are appropriately addressed.
• All relevant controls identified in the CIS Controls list are implemented.
• We strongly recommend that you undertake an external penetration test at least every 12 months during your accreditation.

Authentication

Server validated multi-factor authentication must be required for all users of your application's Akahu functionality.

Multi-factor authentication may occur at the time of device registration (mobile apps), login (web apps), or on-demand before allowing the user to take action (e.g. initiate a payment). If your application grants long-lived authentication, see our requirements for Persistent Sessions below.

Allowable multi-factor authentication methods include:

• Username + password¹ + SMS code
• Username + password² + authenticator code
• Username + server-validated PIN³ + SMS code
• Passkeys/FIDO2⁴

^1,2Passwords must have high quality strength requirements (minimum length & character variation).

³PINs must be 5 digits minimum and server-validated with a conservative rate limit (e.g. 5 attempts per minute).

⁴ User verification must be required for passkey based authentication flows. Processes for registering a new passkey (including "lost/reset passkey" functionality) must use multiple factors of authentication.

Read only access

We have less strict authentication requirements if you are only requesting read access to users' accounts via Akahu. Allowable authentication methods for read-only access include:

• Username + password¹
• A short lived, single use URL or 6+ digit code sent via SMS or email

¹Passwords must have high quality strength requirements (minimum length & character variation).

Persistent sessions

Web applications that allow sessions that last more than 2 hours (including "keep me logged in") must expire the MFA status of a session after 2 hours. After expiry, the MFA status of the session must be renewed (by the user completing another MFA challenge) before allowing the user to initiate payments via Akahu.

Mobile applications that use a long-lived client side access/refresh token must implement either:

• A PIN lock (can be client-validated)
• A secure biometric lock

Consumer controls

Your application must provide functionality that gives the user accurate visibility and control over their connected accounts. To become accredited, your application must:

• Provide a summary of the accounts that the user has connected via Akahu. This should be available to the user regardless of the status of their account with you (e.g. their subscription tier with your application).
• Provide a way for a user to revoke your access to their connected accounts. You can implement this either individually per-authorisation (via DELETE /authorisations/{id}) or for all authorisations (via DELETE /token).
• Revoke all access to a user's accounts when they delete their account with you (via DELETE /token).
• Gracefully handle the user access token being revoked externally (e.g. the user logs in to my.akahu.nz and revokes your app's access). This can be implemented by either:
  • Subscribing to and handling the TOKEN DELETE webhook, or
  • Handling 401 response codes from the Akahu API (which indicate that the user access token is no longer valid).
• Show an alert or notification to the user when the status of one of their connected accounts becomes INACTIVE. The user should be prompted back to the Akahu OAuth flow to resolve this issue.

More guidance on creating a high quality Akahu experience for your users can be found in this guide.

📘

Data Privacy

In accordance with New Zealand’s Privacy Act 2020, you may only retain user data for as long as it is reasonably required by your application. Please consider this obligation when a user revokes your access to their accounts - it is your responsibility to ensure that you delete user data that has been exchanged via Akahu and is no longer reasonably required.