Data Processing Addendums For Fintech Platforms

Do you need a data processing addendum before you onboard business customers to your fintech or payments platform? Usually, yes, especially if your platform handles personal information, transaction records, card-related data, bank account details or identity verification information for those customers.

The reassuring part is that a data processing addendum doesn't need to be complicated. It just needs to clearly explain who can do what with the data, how it will be protected, and what happens if something goes wrong.

For many New Zealand fintech businesses, a good DPA sits alongside your privacy policy and platform terms. Together, they help your customers trust you with sensitive data and make your legal position much clearer from day one.

Do Fintech Platforms Need A Data Processing Addendum In New Zealand?

Yes, most fintech platforms should have a data processing addendum if they handle personal information on behalf of business customers. It may not be called a DPA under the Privacy Act 2020, but the commercial need is very real.

New Zealand privacy law doesn't use the same controller and processor language as the GDPR. Instead, the Privacy Act 2020 talks about agencies and sets out Information Privacy Principles, often called IPPs, covering collection, use, disclosure, security, access, correction and more.

That means you shouldn't simply copy a GDPR-style processor agreement and assume it works in New Zealand. Your DPA should reflect how your platform actually operates under New Zealand law and under the expectations of your customers.

A DPA is especially useful if your platform:

• Processes payments for your customer's end users
• Stores names, emails, phone numbers or customer IDs
• Handles bank account numbers, transaction histories or card-related information
• Uses identity verification, fraud monitoring or risk scoring tools
• Shares data with cloud hosting providers, analytics tools or overseas service providers
• Provides dashboards, reporting or reconciliation tools to business customers

Without a written DPA, your customer may keep sending you privacy questionnaires, security review requests and contract mark-ups. More importantly, you may not have clear limits on what you can do with the data, who is responsible for privacy requests, or how quickly you need to notify the customer about a breach.

What Should A Data Processing Addendum Cover Under The Privacy Act 2020?

A good DPA should cover the practical points that matter under the Privacy Act 2020: what information you receive, why you use it, how you protect it, when you disclose it, and what each party must do if an individual exercises privacy rights.

The Privacy Act's IPPs don't give you a ready-made DPA checklist. Instead, they create obligations that your contract should support. For a fintech platform, the main areas are usually collection, use, security, retention, disclosure and access or correction requests.

Core Clauses To Include

Your DPA should usually cover:

• Scope of data: the categories of personal information and financial data your platform processes
• Purpose: what you can use the data for, such as payment processing, fraud prevention, reporting, support and compliance
• Customer instructions: when you must follow your customer's instructions and when you can act independently to meet legal, scheme or security obligations
• Security measures: the technical and organisational steps you take to protect data
• Sub-processors: when you can use third-party providers and how you tell customers about them
• Overseas disclosures: where data may be sent or accessed from outside New Zealand
• Privacy requests: who responds when an individual asks to access or correct their information
• Breach notification: how quickly you notify the customer and what information you provide
• Retention and deletion: what happens to data during and after the customer relationship
• Audit and assurance: what evidence you can provide about your security and compliance practices

For example, if your platform needs to keep transaction records for 7 years for tax or financial recordkeeping reasons, or keep AML/CFT records for the required retention period, your DPA should explain that data may not always be deleted immediately when a customer leaves. Otherwise, your customer may expect instant deletion and you may end up with a contract promise you can't safely keep.

How Is A DPA Different From A Fintech Privacy Policy Or Terms Of Use?

A DPA is different because it deals with your relationship with your business customer about data handling. Your privacy policy speaks to individuals, and your terms of use set the broader rules for using your platform.

For a fintech business, these documents often work together. They shouldn't contradict each other, and each one should do a different job.

Privacy Policy

Your privacy policy explains how your business collects, uses, stores and discloses personal information. In New Zealand, this helps you meet Privacy Act 2020 transparency expectations, especially around collection, purpose, disclosure and access rights.

If individuals interact directly with your platform, such as merchants, payer contacts, directors, staff users or end customers, your privacy policy should explain that clearly. It should also deal with overseas storage or access where relevant.

Fintech Terms Of Use

Your terms of use usually cover the commercial relationship with your customer. For example, they may deal with account setup, permitted use, fees, support, suspension, limitations of liability, an acceptable use policy, intellectual property and termination.

For payment platforms, the terms may also need to cover payment flows, settlement timing, chargebacks, refunds, fraud controls and customer responsibilities. You should be careful that your terms don't make privacy or security promises your operations team can't actually meet.

Data Processing Addendum

Your DPA goes deeper on data. It should explain the processing activities, security expectations, sub-processors, breach procedures and return or deletion rules.

A template can be a useful starting point, but fintech data flows are rarely generic. Your DPA should be tailored before you use it, especially if you process financial information, use overseas infrastructure or support regulated customers.

How Should You Deal With Sub-Processors And Overseas Data Disclosures?

You should deal with sub-processors and overseas data disclosures clearly and upfront, because this is one of the first things business customers ask about during onboarding.

A sub-processor is usually a third party that helps you provide the platform and can access or process customer data. For a fintech platform, this might include:

• Cloud hosting providers
• Payment processors or banking infrastructure providers
• Identity verification providers
• Fraud monitoring tools
• Customer support platforms
• Email, SMS or notification providers
• Analytics, logging or observability tools

Your DPA should say whether you can appoint sub-processors without case-by-case approval. Many platforms use a general authorisation model, where customers accept a listed group of providers and receive notice of material changes.

Overseas access also needs careful handling. Under IPP 12 of the Privacy Act 2020, if you disclose personal information to a foreign person or organisation, you generally need to have reasonable grounds to believe the information will be protected by comparable privacy safeguards, unless another exception applies. Sometimes overseas storage or processing by an agent may be treated differently from a disclosure, but you should still explain the arrangement clearly.

In practice, your DPA should identify:

• The countries or regions where data may be stored or accessed, if known
• The types of overseas providers you use
• The contractual safeguards you require from those providers
• How customers are notified about new material providers
• Whether customers can object and what happens if they do

This isn't just a legal issue. If your customer is a bank, insurer, accounting platform or larger merchant, they may have their own vendor risk processes. A clear sub-processor and overseas disclosure clause can speed up onboarding and reduce back-and-forth.

What Security And Breach Terms Should You Include?

Your DPA should include security and breach terms that are specific enough to be useful, but not so rigid that you accidentally promise an exact control you may later change.

The Privacy Act 2020 requires agencies to protect personal information with reasonable security safeguards against loss, unauthorised access, use, modification, disclosure and other misuse. For fintech platforms, customers will usually expect more detail because the data can be sensitive and commercially valuable.

Your DPA might refer to measures such as:

• Access controls and role-based permissions
• Multi-factor authentication for staff systems
• Encryption in transit and, where appropriate, at rest
• Logging and monitoring of system activity
• Secure software development and change management
• Regular vulnerability management
• Staff confidentiality and security training
• Incident response procedures
• Business continuity and backup processes

If you handle card data, you may also need to meet card scheme and PCI DSS requirements. Those aren't the same as the Privacy Act, but customers often expect your contracts to reflect them where they apply.

For breaches, New Zealand has a notifiable privacy breach regime. If a privacy breach has caused, or is likely to cause, serious harm, the Privacy Commissioner and affected individuals generally need to be notified as soon as practicable.

Your DPA should set a clear internal notification process between you and your customer. For example, you might agree to notify the customer without undue delay after confirming an incident affecting their data, then provide updates as you investigate. Be careful with fixed deadlines like 24 hours if your team can't reliably meet them.

What Does A Practical DPA Look Like For A Payments Platform?

A practical DPA looks like a short, clear operating manual for customer data, not a dense document no one in your business can follow.

Say Aroha runs PayNest, a Wellington-based payments platform for gyms and fitness studios. PayNest processes membership payments for 120 gyms and holds personal information for about 80,000 members, including names, email addresses, membership IDs, payment status, transaction history and masked card details.

PayNest uses a New Zealand support team, a cloud hosting provider with servers in Australia, an overseas fraud monitoring tool, and an email notification provider as sub-processors. A large gym chain asks PayNest for a data processing agreement before signing a 12-month subscription.

PayNest's DPA could say:

• PayNest may process member data to provide payments, billing, reconciliation, fraud monitoring, support and legally required recordkeeping
• The gym remains responsible for giving appropriate privacy notices to its members where it collects the information
• PayNest will apply reasonable security safeguards, including access controls, encryption in transit and staff confidentiality requirements
• PayNest may use listed sub-processors, including hosting, fraud monitoring and email providers
• Some data may be accessed or stored outside New Zealand, and PayNest requires contractual privacy and security safeguards from those providers
• PayNest will assist the gym with reasonable access or correction requests relating to member data
• After termination, PayNest will delete or return customer data within a stated period, except where retention is needed for legal, compliance, fraud prevention or accounting reasons

The outcome is practical: the gym gets comfort on data handling, PayNest avoids negotiating the same points from scratch each time, and both sides know what happens if a member asks about their information or an incident occurs.

Data Processing Addendum Template: What Should You Include?

Your DPA should be tailored to your platform, but a clear clause outline can help you map what needs to be covered before you get it drafted or reviewed.

Here is a practical fill-in outline you can use as a starting point. It isn't a finished legal document, and you should have it tailored before you send it to customers.

1. Parties And Background: name your platform, the business customer and how the DPA connects to your main terms or customer agreement.
2. Definitions: define customer data, personal information, services, security incident, sub-processor and applicable privacy laws.
3. Scope Of Processing: describe the categories of information, types of individuals and processing activities your platform performs.
4. Permitted Purposes: state exactly what you can use the data for, including support, security, fraud prevention and compliance where needed.
5. Customer Responsibilities: explain what your customer must handle, such as lawful collection, notices, consents and account user permissions.
6. Security Safeguards: summarise your technical and organisational security measures without overpromising fixed controls.
7. Sub-Processors: set out your approval model, notice process and how you manage third-party providers.
8. Overseas Access And Disclosure: explain where data may go and what safeguards apply under the Privacy Act 2020.
9. Privacy Requests: set out how access, correction and deletion requests are handled between you and your customer.
10. Security Incidents And Breaches: include notification steps, cooperation duties and who handles external notifications.
11. Retention, Return And Deletion: explain what happens during the subscription and after termination, including legal retention exceptions.
12. Audit And Assurance: describe what reports, certifications or reasonable information you can provide to customers.
13. Liability And Order Of Precedence: explain how the DPA interacts with your main contract, especially if clauses conflict.

Before you use the outline, check it against your actual product. If your product team collects extra event logs, metadata, IP addresses or device data for fraud detection, the DPA should reflect that. Hidden data flows are often what cause trouble later.

Key Takeaways

• A data processing addendum is usually a smart move for New Zealand fintech and payments platforms handling customer or end-user data.
• The Privacy Act 2020 doesn't use GDPR-style processor language, so your DPA should be adapted for New Zealand law and your real data flows.
• Your DPA should cover permitted use, security, breach handling, sub-processors, overseas access, privacy requests and deletion or retention.
• Your privacy policy, platform terms and DPA should work together without making inconsistent promises.
• Clear data terms can make customer onboarding faster, especially with larger merchants, SaaS partners and regulated customers.

If you'd like help with your data processing addendum, fintech privacy terms, customer contracts or overseas data disclosure clauses, you can reach us at 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.