DCS Data Submission Guidelines 3
IN CONFIDENCE

Introduction
This document, together with appendices to the Depositor Compensation Scheme (DCS) Guidance 1 , sets out the format that deposit takers must use to provide data to the Reserve Bank and specifies the depositor information and Single Depositor View (SDV) information required under clause 3 of the DCS Standard.
Data variables
Appendix 1 of the Guidance outlines the data variables to be captured in a Depositor Information
File (DIF) through either the DCS Depositor Page or the Alternate Model and includes supporting definitions for each variable. The DIF must include the unique identifier to enable accurate matching with records from the SDV. Authorised individuals, using the DCS Depositor Page, have the option to provide an email address and phone number voluntarily. Since providing this information is voluntary for authorised individuals, the data provision requirement for email address and phone number is non-mandatory for deposit takers i.e., only required if the data is available. Refer to Appendix B of this document for more information.
Appendix 2 of the Guidance outlines the data variables contained within the SDV and provides a
definition of each variable. The data variables reflect industry-agreed definitions developed through discussions with deposit takers.
2.1 Primary keys
A unique identifier and account number(s) are required for each depositor in the SDV file. The unique identifier is generated by the deposit taker to identify a depositor. The unique identifier and account number are required in the SDV to enable the Reserve Bank to identify and manage depositor records for the purposes of calculating and paying DCS entitlements. Similarly, a unique identifier and a pay to account number are required for each depositor in the DIF. The Reserve Bank will use the unique identifier to link depositor records in the DIF and SDV for the same depositor (for example, unique identifier 123 in the DIF to be linked with identifier 123 in the SDV) to pay DCS entitlements.
2.2 Timestamps
This is the timestamp to be captured and recorded in the DIF. ISO 8601 is the international standard format for representing dates and timestamps. It is widely used in APIs, databases and logs and therefore, we require timestamps to follow the international standard using the following format:
2026-05-07T14:30:45
Breakdown:
 2026-05-07 → date (YYYY-MM-DD)
 T → separator between date and time

1 DCS Guidance [Add link here]

DCS Data Submission Guidelines 4
IN CONFIDENCE
 14:30:45 → time (HH:MM:SS)
Please note, the timestamp format for file naming is different from this and elaborated in Appendix A.
2.3 Flags
Where a data variable name includes a suffix of FLG, that variable is a Boolean data item and should contain ‘TRUE’ if true or ‘FALSE’ if false.
2.4 Factor variables
Some fields are represented as categorical fields. These are based on the information recorded in the deposit takers’ systems, for example, depositor type in the deposit taker’s system is recorded as “Individual”. These are listed as factor variables in the SDV variables list. If your text strings contain internal codes, please provide supporting labels or descriptions separately in the accompanying file. If you store additional information for factor variables using sub-types, please provide both the sub-type and its parent category. For example, if the customer type is listed as 'XYZ Group' and the sub-category is 'Incorporated Society', both should be provided in the SDV depositor type field as 'XYZ Group-Incorporated Society'.
2.5 Numeric variables
Numeric variables should only contain numbers (integers or decimals). They should not include characters, spaces, letters etc.
3. File format options
All files must be prepared using the following specification. The Reserve Bank requires a CSV UTF8 (Comma delimited). Use of Excel to generate CSV files is not recommended, as it often automatically reformats data in ways that may lead to inconsistencies or errors. Tab Description CSV (Comma Separated Values) Refer to section 3 for detailed requirements
3.1 Required data formats
Type of variable Required format
Specified code  INSTITUTION_CODE per Appendix C  All addresses will follow format as NZ Post Addressing standards Date YYYY-MM-DD Amount No $ signs, no numeric comma separators, apply bankers rounding and leave up to 2 decimal places

DCS Data Submission Guidelines 5
IN CONFIDENCE
Type of variable Required format
Percentage (Withholding
Tax Rate)
Number only, leave up to 3 decimal places, no % signs for example, 0.175 for a Withholding Tax Rate of 17.5%. Boolean (TRUE / FALSE) Use TRUE (capitalised) if true, FALSE if false. Text string Unless specified, as held in your system - if these are your internal codes, please provide labels and descriptions in the accompanying file. Note: Ensure there are no leading or trailing spaces. Not applicable or missing data Please leave blank without any leading or trailing spaces. Negative values All negative values to be captured and provided as is, with the exception of credit cards. Only positive values associated with credit cards should be captured and provided. For consistency in reporting, negative balances should be presented with a leading minus sign (-) rather than enclosed in brackets. For example, report -100.00 instead of (100.00). Currency Only amounts that are in NZD are covered by the DCS.
3.1 Data transfer guidance for DIF
Create data files
First data transfer
The deposit taker must generate the DIF(s) that contain the depositor information specified in the Guidance. The files must be provided in CSV format, as specified in this document. The DCS information-gathering notice under section 99 of the DTA will specify requirements about the timing of the first data transfer. Subsequent data transfers The Reserve Bank expects that the deposit taker will need to make multiple data transfers to provide the Reserve Bank with all depositor information as it is collected over time. The information-gathering notice will specify requirements about the frequency of subsequent data transfers (for example, every 24 hours). After the first data transfer, it is required that subsequent transfers contain only depositor information that is new (i.e. does not contain any record from previous data transfers) (delta data). An update to any data variable within a depositor record constitutes an updated record and should be included in subsequent transfers, for example, if account name is updated then that record is required to be included in subsequent transfers.

DCS Data Submission Guidelines 6
IN CONFIDENCE
Notify the Reserve Bank of transfer
The DCS information-gathering notice will likely require the deposit taker to notify the Reserve Bank each time a data file is transferred to the Reserve Bank using Box. The notice will also likely require the data file to be accompanied by certain information about the transferred data (such as file names and version numbers) and relevant contact persons. The Reserve Bank will, in the DCS information-gathering notice, provide a template for the notification email and accompanying information. The Reserve Bank will confirm receipt The Reserve Bank will send an email notification to confirm receipt of the transferred data file. This will not confirm that the data is complete or accurate. The Reserve Bank will send a second email notification to confirm all data files are complete and accurate. If any errors are detected, the Reserve Bank will contact the deposit taker to help resolve them.
3.2 Encoding, Compression, and Encryption
For an efficient and reliable transmission of a submission, all files must adhere to the following standards:

All files are encoded using UTF-8. This is to ensure that characters like macrons are accurately
represented in the extract.
Files are prepared and then placed into a single archive file. Refer to Process Overview in
Appendix A for further details.
All files included in the archive are compressed before providing to the Reserve Bank to avoid
exceeding the file size capacity of the file transfer application. The current maximum file size capacity is 500MiB per file.
Please refer to Appendix A for detailed instructions on file naming and tar archive formatting.
All parts must be provided together to ensure successful processing upon arrival. The Reserve Bank understands that only the DIF will require subsequent transfers.
SDV is only provided as a single CSV file.
The archive file must be encrypted.
The archive file names must be compliant with the naming conventions.
See Appendix A for details on preparation of the files before they are provided to the Reserve bank.

DCS Data Submission Guidelines 7
IN CONFIDENCE
4. File Layout – CSV data files
CSV is the required format for the SDV, DIF, the accompanying file and the manifest. Provide your data in CSV format (using a pipe – vertical bar separator). Use the data item names and data formats contained in the variable lists in Appendix B.
4.1 File Types
File Description
SDV Refer to part 5 of the DCS Standard and Appendix 1 of the Guidance.
Accompanying file For each factor variable in the SDV variables list, except for tax variables, provide a list and definitions for all categories and sub-categories (if any) used internally. If your dataset uses internal codes, please also provide the corresponding labels or descriptions in the accompanying file. This is necessary so we can align the categories provided with the standardised category list maintained in our systems. If usernames i.e., codenames are used by authorised individuals to access the DCS Depositor Page, provide the full names of all authorised individuals, together with their associated usernames in the accompanying file. We only require this list when the username provided in the DIF is not a full name. Manifest file The manifest reference file provides metadata to describe each file included in the submission. The DCS information-gathering notice will specify the information that the deposit taker must provide for a complete manifest file. To provide context:

There must only be one manifest file per submission.
There should be a separate section in the manifest file for every file
included in the submission.
Each manifest section should have one header row with a unique file
name.
Depositor information file The Reserve Bank expects that the deposit taker will need to make multiple data transfers to transfer all alternate account information as it is collected over time. Information captured using the alternate model, will also need to be provided using the depositor information file template structure. This means providers must retain the full set of column headers, with the exact CSV names specified, keep the columns in the specified order, and leave non-applicable fields blank. Refer to Appendix 2 of the Guidance for more information on the order of columns and part 2, 3 and 4 of the DCS Standard for further information.
4.2 File structure
All variables / columns listed in the variable list must be captured and recorded in the SDV and
DIF in the correct order, specified in Appendix B. If a value is missing or unavailable, leave the field contents blank without any leading or trailing spaces.

DCS Data Submission Guidelines 8
IN CONFIDENCE
2. Variable / column names must be kept in uppercase with underscore separators and the full
name, as specified in appendix B. Modern databases support more than 30 characters for a column. While we will endeavour to keep variable names concise, please ensure that the CSV header complies with the file specification.
3. File format is a well-formed CSV file.
4. The CSV file contains header information and pipe (vertical bar) | separated data.
5. The file follows the template in Appendix D. Files are included in a single archive file.
6. The file is encrypted using asymmetric encryption.
Refer to Appendix D for the layout of the CSV file. All files are mandatory. For more information, refer to the Guidance.
4.3 Header row for SDV and DIF
The header row contains the names of each data item.

Contains the names of all data items using values from “CSV variable names” column of the
SDV and DIF, specified in Appendix B.
Ensure the column header names are in uppercase, and any specified underscores in the
variable name are retained e.g. POST_CODE.
Use a pipe (vertical bar) separator between each column rather than a comma. That is the |
character.
Key columns for the SDV are UNIQUE_ID and ACCOUNT_NUM.
Key columns for the DIF are UNIQUE_ID and PAY_TO_ACCOUNT_NUM.
4.4 Data rows
For both SDV and DIF, the data rows start from the second row of the CSV file. The first row is the header and contains the CSV variable names. Specifically, for SDV, each row must be unique across the whole file for the given primary keys. For example, the combination of a unique identifier and account number in each row must be unique. For joint accounts, we require each depositor to have their own record in the CSV file, identified by their unique identifier and the account number. Depositors with a joint account with the deposit taker must appear with each depositor’s list of distinct account records. For joint account balance, the full positive balance must be shown in each record belonging to each depositor; deposit takers must not split it for reporting the balance. See Appendix D for an illustrated example. As per part 5, para 76 of the Guidance, if the deposit is made by credit card, do not enter the full card number in the SDV account number field. Instead, provide a unique number, such as the last 8 digits or another number that it can identify back to a credit card of the depositor. Supplying the full number may be a breach of Payment Card Industry Data Security Standard (PCI-DSS) Standards.
Appendix A: File archive, naming and encryption requirements
Please use this appendix as a guide for preparing file submissions.

DCS Data Submission Guidelines 9
IN CONFIDENCE
All files must be packaged before providing to the Reserve Bank to meet security controls. The steps are:
 Adding all files into a single archive file. Supported archive formats are tar – Unix centric systems or zip – Windows centric systems.  Ensuring the archive file is compressed (for efficient transfer).  Ensuring the archive is encrypted using an approved method prior to loading to BOX. BOX is the preferred method of file transfer unless otherwise stated.  Ensuring the archive file is correctly named – see naming standards below. Process overview The following example provides an illustration of the steps to creating an encrypted tarball - tar archive format:
 All files to be provided are prepared and extracted into a working directory. Files are expected to be named using the data file naming standards detailed below.  All files in the working directory are added to a tarball using tar for each submission Working file: DCS_Institutioncode_1_20260930101801_20261001101801.tar  The tarball file is compressed using gzip (if it wasn’t completed in the prior step) Working file: DCS_Institutioncode _1_20260930101801_20261001101801.tar.gz  The compress tarball file is encrypted using GNU Privacy Guard (gpg) utility. This will be encrypted using the Public Key provided by the Reserve Bank. Working file: DCS_Institutioncode _1_20260930101801_20261001101801.tar.gz.gpg  The final encrypted tar archive file:
DCS_Institutioncode_1_20260930101801_20261001101801.tar.gz.gpg is provided to the Reserve Bank via BOX. Encryption overview This section is updated to reflect our response to the consultation feedback. As most deposit takers have indicated that they can comply with asymmetric encryption, we are specifying only asymmetric encryption. Encryption refers to the process of encoding information in such a way that only authorised parties can access it. It is a critical security mechanism employed to protect data during transmission (in transit) and while stored (at rest). Encryption safeguards sensitive content, including personal data, financial transactions, and confidential business communications from unauthorised access and manipulation. Asymmetric encryption Asymmetric encryption utilises a pair of cryptographic keys: a public key for encryption and a corresponding private key for decryption.  Mechanism: Any party may use the public key to encrypt a message. However, only the holder of the corresponding private key (RBNZ Regulatory DCS data system) can decrypt and access the original content.

DCS Data Submission Guidelines 10
IN CONFIDENCE
 Advantages: Eliminates the need for shared key / password; improves confidentiality across distributed systems.  Limitations: May exhibit reduced performance in some implementations compared to symmetric encryption. This, however, is mitigated using the GNU Privacy Guard implementation.  Implementation Policy: Asymmetric encryption is the recommended standard for all data protection activities unless explicitly superseded by approved exceptions. Archive file naming standard The encrypted archive files have a set naming convention so the Reserve Bank can correctly decrypt and unpack the submission for a given period. The required elements for each file type are listed in the table below. File Type Encrypted Archive file Example DCS_InstitutionCode_1_20260930101801_20261001091801.tar.gz.gpg Description “In the form of <File Collection><Entity Code><Archive Partition Number><Quantification time><Create Timestamp>.<archive suffix>”  File collection – DCS.  Entity or institution code as per Appendix C.  Archive partition number – Indicates the file number sequence if an archive file is split into multiple parts due to size limitations. Default value is 1.  Quantification time - The data as at period e.g. End of September 2026 =
20260930101801. Format – YYYYMMDDhhmmss. Quantification time will be
specified in the notice issued by the Reserve Bank.
 Create timestamp – The timestamp of when the individual file is created or extracted e.g. 20261001091801 format – YYYYMMDDhhmmss. Following ISO 8601- 1:2019 standard.  Archive suffix – A valid suffix that meets the compression, archive, and encryption method. Valid suffixes are:
 .zip.gpg (Encrypted zip archive) a. .tar.gz.gpg (Encrypted compressed tar archive Note: Do not include a folder structure within the DCS Submission Archive, just add the individual submission files without a parent directory. The relevant files contained within the archive must adhere to the naming convention outlined above. However, instead of an archive partition number, each file within the archive must include a version number. For depositor information files provided with delta data, this version number will be replaced with a sequence number. This is because a key challenge in delta processing is ensuring that all files are received and processed in order, without any omissions. Therefore, the archive partition number will be replaced by a version number for files such as the SDV, manifest, and accompanying files. For DIF, the archive partition number will be replaced by a sequence number.

DCS Data Submission Guidelines 11
IN CONFIDENCE
Supported archive types
All files provided to the Reserve Bank must be added to one of the following archive formats listed in the table below. Archive Format Expected File extension Encryption Method Notes Tar *.tar.gz.gpg Asymmetric – gpg (post archive creation) A "tar archive" (also known as a "tarball") is a file format that bundles multiple files into a single archive file used mostly by Unix/Linux systems. Note: The tar archive must also be compressed using gzip to reduce the file size. Zip *.zip.gpg Asymmetric – gpg (post archive creation) A "zip archive" is a common archive file format that bundles multiple files into a single archive file Encryption secret The Reserve Bank will adopt the same asymmetric encryption as Loan-level data (LLD) for DCS submitted files at rest. It is Gnu Privacy Guard (GPG) as the preferred implementation based on the OpenPGP standard (defined in RFC 9580) 2 . The solution will be implemented so that files encrypted in an OpenPGP-compatible format, including PGP- or GPG-generated encrypted files that GPG can decrypt, are supported by the Reserve Bank’s ingestion process. We have received feedback during consultation on whether PGP can be used, our guidance in this case is that it needs to be compatible with Gnu Privacy Guard (GPG) version 2.2.27 or above. Where Pretty Good Privacy (PGP) is used, deposit takers should undertake appropriate testing to confirm compatibility before providing files to the Reserve Bank. The Reserve Bank will provide a public key (asymmetric encryption). Further information regarding the sharing of the key will be specified directly with the deposit taker when needed. Asymmetric encryption notes:
6. Asymmetric encrypted files should be created or compatible with Gnu Privacy Guard (GPG)
version 2.2.27 or above.
7. Do not enable the "armor" setting when creating an asymmetrically encrypted file, as it
unnecessarily increases the file size. Note: You only need to enable this option if you plan to email the file. This is not a supported method.
8. Create an archive e.g. *.zip or *.tar.gz then encrypt the archive.
9. Public key algorithm: RSA (2048-bit key length)
10. Preferred symmetric cipher: AES-256 (additional support noted for AES-192, AES-128, and
3DES but does not align with NZISM standards)

2 https://www.openpgp.org/about/standard/

DCS Data Submission Guidelines 12
IN CONFIDENCE
11. Hash algorithms: SHA-512, SHA-384, SHA-256 supported (SHA-256 or stronger preferred;
please avoid SHA-1).
12. Asymmetric encrypted files should have a final file extension of *.gpg. Examples:
a. DCS_INSTITUTIONCODE_1_20260930101801_20261001091801.zip.gpg b. DCS_INSTITUTIONCODE _1_20260930101801_20261001091801.tar.gz.gpg
c. While the Reserve Bank cannot provide direct advice, there is a Python Library (pythongnupg) which supports programmatic Pythonic creation and decryption of GPG encrypted
files. This python library is a wrapper for the GPG utility.
Appendix B: CSV names for DIF and SDV
Where fields are mandatory, information must be provided. For more information on mandatory variables, refer to part 4 of the Guidance. DIF Deposit takers are required to provide a Depositor Information File (DIF), regardless of whether they use the DCS Depositor Page or the Alternate Model. Deposit takers who are using the Alternate Model may leave the following columns in the submission template blank: email address, phone number and username. Email address and phone number will already be supplied using the SDV. The columns, including the exact column name and order must be maintained in the submission template even if the fields are to be left blank.

Field identifier CSV variable names

1 Unique identifier UNIQUE_ID
2 Pay to account number PAY_TO_ACCOUNT_NUM
3 Pay to account name PAY_TO_ACCOUNT_NAME
4 Email address EMAIL_ADDRESS
5 Phone number PHONE_NUM
6 Timestamp TIMESTAMP
7 Username USERNAME
SDV

Field identifier in the SDV CSV variable names

1 Unique identifier UNIQUE_ID
2 Type of depositor DEPOSITOR_TYPE

DCS Data Submission Guidelines 13
IN CONFIDENCE

Field identifier in the SDV CSV variable names

3 Depositor ineligibility reason DEPOSITOR_INELIGIBILITY_REASON 4 First name(s) of the depositor FIRST_NAME 5 Middle name(s) MIDDLE_NAME 6 Surname SURNAME 7 Date of birth BIRTH_DATE 8 Entity name ENTITY_NAME 9 New Zealand Business Number (NZBN) NEW_ZEALAND_BUSINESS_NUM 10 New Zealand Company Number NEW_ZEALAND_COMPANY_NUM 11 IRD number IRD_NUM 12 Withholding tax rate WITHHOLDING_TAX_RATE 13 Withholding tax type WITHHOLDING_TAX_TYPE 14 Preferred contact method PREFERRED_CONTACT_METHOD 15 Postal/physical address POSTAL_OR_PHYSICAL_ADDRESS 16 Address line 2 ADDRESS_LINE_2 17 Address line 3 ADDRESS_LINE_3 18 Address line 4 ADDRESS_LINE_4 19 Address line 5 ADDRESS_LINE_5 20 Post code POST_CODE 21 Country COUNTRY 22 Email address EMAIL_ADDRESS 23 Phone number 1 PHONE_NUM_1 24 Phone number 2 PHONE_NUM_2 25 Compensation amount COMPENSATION_AMT 26 Vulnerability VULNERABILITY 27 Account number ACCOUNT_NUM 28 Number of account holders ACCOUNT_HOLDERS_NUM

DCS Data Submission Guidelines 14
IN CONFIDENCE

Field identifier in the SDV CSV variable names

29 Product type PRODUCT_TYPE
30 Product name PRODUCT_NAME
31 Protected deposit PROTECTED_DEPOSIT_FLG
32 Relevant arrangement RELEVANT_ARRANGEMENT_FLG 33 Trust account TRUST_ACCOUNT_FLG 34 Account balance ACCOUNT_BALANCE 35 Accrued interest amount ACCRUED_INTEREST_AMT 36 Authority on account AUTHORITY_ON_ACCOUNT_FLG 37 Type of authority AUTHORITY_TYPE 38 First name(s) of the authority AUTHORITY_FIRST_NAME 39 Middle name(s) of the authority AUTHORITY_MIDDLE_NAME 40 Surname of the authority AUTHORITY_SURNAME 41 Authority: Email address AUTHORITY_EMAIL_ADDRESS 42 Authority: Phone number AUTHORITY_PHONE_NUM 43 Payout hold status PAYOUT_HOLD_STATUS
Appendix C: Entity/institution codes
See below for Institution codes for all the New Zealand registered deposit takers. Branches are excluded as they are not covered by the DCS. Please use the following Institution code, where applicable. Deposit takers Institution codes ANZ Bank New Zealand Limited ANZN ASB Bank Limited ASB Bank of Baroda (New Zealand) Limited BOB Bank of China (New Zealand) Limited BOC Bank of India (New Zealand) Limited BOI

DCS Data Submission Guidelines 15
IN CONFIDENCE
Deposit takers Institution codes
Bank of New Zealand (BNZ) BNZ
China Construction Bank (New Zealand) Limited CCB Christian Savings Limited CSL Finance Direct Limited FDL First Credit Union Incorporated FCU General Finance Limited GFL Gold Band Finance Limited GBFL Heartland Bank HBL Heretaunga Building Society HBS Industrial and Commercial Bank of China (New Zealand) Limited ICBC Kiwibank Limited KIWI Liberty Financial Limited LFL Mutual Credit Finance Limited MCFL Nelson Building Society NBS Police and Families Credit Union PFCU Rabobank New Zealand Limited RNZL SBS Bank SBS The Co-operative Bank COOP TSB Bank Limited TSB Unity Credit Union UCU Wairarapa Building Society WBS Welcome Limited WELC Westpac New Zealand Limited WNZL XCEDA Finance Limited XFL

DCS Data Submission Guidelines 16
IN CONFIDENCE
Appendix A:
The following construct exhibits how the SDV is required to be provided. The Depositor Information File will follow a similar format. The CSV file contains 43 columns, but due to space limitations in this document, the columns are displayed across multiple tables for presentation purposes only. When providing, all data variables must be included as columns in a single CSV file. Each row must align with the appropriate column headers, and the file must contain only one header row listing all variable names. The construct contains examples surrounding two different scenarios:
 Depositor with unique identifier 22001 is a depositor with a hearing impairment who maintains two accounts with the deposit taker: a personal transaction account and a joint account with their partner. The partner has the unique identifier 22000. We assume none of the accounts have accrued interest to be paid.  Depositor with unique identifier 22002 is a depositor who maintains two accounts with the deposit taker: a term deposit that is not associated with their sole trader business, and a business savings account held under their sole-trader trading name. UNIQUE_ID DEPOSITOR _TYPE DEPOSITOR_INELIGIBILITY_REASON FIRST_NAME MIDDLE_NAME SURNAME 22001 Individual East North South 22001 Individual East North South 22000 Individual North South 22002 Individual West Northwest 22002 Individual West Northwest BIRTH_DATE ENTITY_NAME NEW_ZEALAND_BUSINESS_NUM NEW_ZEALAND_COMPANY_NUM IRD_NUM 1832-01-02 123-456-789 1832-01-02 123-456-789 1832-01-04 123-455-555 1832-01-03 123-459-111 1832-01-03 West North and Co. 124958372892 123-459-111

DCS Data Submission Guidelines 17
IN CONFIDENCE
WITHHOLDING_TAX_RATE WITHHOLDING_TAX
_TYPE
PREFERRED_CONTACT_METHOD
0.33 RWT Email
0.33 RWT Email
0.33 RWT Email
0.39 RWT
0.39 RWT
POSTAL_OR
_PHYSICAL_ADDRESS
ADDRESS_LINE_2 ADDRESS_LINE_3 ADDRESS_LINE_4
3/17 Terrace Wellington Central Wellington
3/17 Terrace Wellington Central Wellington
3/17 Terrace Wellington Central Wellington
2/25 Terrace Wellington Central Wellington
2/25 Terrace Wellington Central Wellington
ADDRESS_LINE_5 POST_CODE COUNTRY EMAIL_ADDRESS 1234 NZ East.auto1@hmail.com 1234 NZ East.auto1@hmail.com 1234 NZ East.abc@hmail.com 1234 NZ xyz.auto@hmail.com 1234 NZ xyz.auto@hmail.com

DCS Data Submission Guidelines 18
IN CONFIDENCE
PHONE_NUM_1 PHOME_NUM_2 COMPENSATION_AMT VULNERABILITY +760385720922 +760385720911 98000.00 Hearing impairment +760385720944 +760385720933 98000.00 Hearing impairment +760385724444 +760385720888 8000.00 +760385720948 +760385720982 100000.00 +760385720940 +7603857209666 100000.00 ACCOUNT_NUM ACCOUNT_HOLDERS_NUM PRODUCT_TYPE PRODUCT_NAME 11-1111-1111111-11 1 Transaction account Everyday account 11-1111-1111111-12 2 Savings account Joint Savings 11-1111-1111111-12 2 Savings account Joint Savings 11-1111-1111112-22 1 Term deposit Super term 11-1111-1111112-33 1 Business savings account Business banking saver PROTECTED_DEPOSIT_FLG RELEVANT_ARRANGEMENT_FLG TRUST_ACCOUNT_FLG ACCOUNT_BALANCE TRUE FALSE FALSE 90000.00 TRUE FALSE FALSE 16000.00 TRUE FALSE FALSE 16000.00 TRUE FALSE FALSE 50000.00 TRUE FALSE FALSE 55000.00 ACCRUED_INTEREST_AMT AUTHORITY_ON_ACCOUNT_FLG AUTHORITY_TYPE AUTHORITY_FIRST_NAME
0.00 FALSE

DCS Data Submission Guidelines 19
IN CONFIDENCE
ACCRUED_INTEREST_AMT AUTHORITY_ON_ACCOUNT_FLG AUTHORITY_TYPE AUTHORITY_FIRST_NAME
0.00 FALSE
0.00 FALSE
5000.00 FALSE
5500.00 FALSE
AUTHORITY_MIDDLE_
NAME
AUTHORITY_SURN
AME
AUTHORITY_EMAIL_AD
DRESS
AUTHORITY_PHONE_
NUM
PAYOUT_HOLD_ST
ATUS