Create a Test Account
Before starting your integration with bronID, you need to create a test account. Visit https://preview.bronid.com/ and create an account using a dedicated email address (e.g., kyc-test@mycompanyname.com). All test accounts must be approved by bronID, and this approval process may take up to 24 hours. The test environment allows unlimited free test submissions during your integration phase.
Important: The test environment only works with test data. To achieve desired verification outcomes, you must carefully follow the test scenarios.
Generate Your Test Credentials and Configure Webhooks
Once bronID approves your test account, you can:
- Generate your test API keys
- Create secret signing keys
- Set up your test webhooks
Generate API Keys
API keys authenticate your requests to bronID. This let’s bronID know that the requests are coming from you. Follow these steps to generate your secret API key in the bronID portal:
1. Access API Key Settings: Log in to your bronID account and navigate to Settings > Developers > API keys
2. Configure Verification Key: Set your Custom verification key. You can use your company name (e.g., mycompanyname) as the verification key. Only lowercase characters are allowed for this field..
3. Set Service Name: Enter your business name as it will appear on KYC forms (if KYC forms will ever need to be used), for example: My Company Name.
4. Generate Keys: Click "Create secret key" to generate your API keys. Use the right-hand menu to enable or disable API keys as needed.
⚠️ Security Notice: Never expose your API keys publicly. Use environment variables and never check your API keys into your Version Control System, e.g. GitHub. Store them securely and restrict access to authorised personnel only.
Generate Secret Signing Keys
Secret signing keys verify that webhooks are genuinely from bronID. They allow you to validate webhook authenticity by comparing signatures generated using these keys against the signatures included in the webhook payload.
To generate your secret signing keys:
1. Access Signing Key Settings: Navigate to Settings > Developers > API keys and then locate the "Secret signing keys" section
2. Generate Keys: Click "Create signing key"
⚠️ Security Notice: Keep your signing keys secure and private. Use environment variables and never check your signing keys into your Version Control System, e.g. GitHub. These keys are crucial for maintaining the integrity of your webhook communication with bronID.
Set Up Your Webhooks
Webhooks allow bronID to notify your system about events in real-time, such as verification status changes, idvRisk status changes, etc. When an event occurs, bronID sends an HTTP request to your configured webhook URL, enabling your platform to respond accordingly.
Your platform can leverage these webhooks in various ways. For instance, you can request additional information from your customer upon receiving an “info” webhook or automatically move customers to the next onboarding step when their status changes to "verified".
To configure your webhooks:
1. Access Webhook Settings: Navigate to Settings > Developers > API keys and find the "Webhook urls" section.
2. Add Webhook Endpoint: Click "Add new webhook". Enter your webhook listener URL (e.g., www.mycompany.com/kycwebhook). This endpoint will receive all webhook updates.
Integrate the ID Verification API
If you're designing your own ID verification forms and flow, you'll need to connect them to the bronID KYC API. This API enables data transmission to bronID for processing and verification, with the verification results returned to your platform.
When building custom forms, you'll need to develop your own front-end interface for customer data collection. You can reference bronID's existing ID verification forms for inspiration on both design and required fields.
bronID supports verification of individuals and organisations across various types and countries. For a streamlined customer experience, we recommend integrating only the entity types and countries relevant to your target customer base.
/verify API Endpoint for Identity Verification
The test bronID API endpoint to verify individuals and organisations is https://dev.bronid.com/verify.
Below are explained the common parameters that you need to submit with each request:
- metadata_version - This is the bronID API version. Current API version is 4.
- metadata_serviceUid - This is the unique identifier of your service. You can find your Service UID by going to Settings > Developers > API keys.
- metadata_secretKey - This is an API key that you can generate in the Settings > Developers > API keys section in the bronID Portal.
- metadata_userId - This is a unique UserID that you can assign for each of your customers (e.g., "U-123-123-12378"). This is an optional field.
- metadata_tags - This is an optional field you can send to bronID if you want to assign the submission to a specific group, such as a product group or department. The tags can be anything that is a logical unit in your operations (e.g., ["Finance Department", "Loans"]). Tags should be a limited list that you can manage via the Portal.
- type - Entity type you are submitting for verification. Here's a list of all possible entity types.
- fields - In this array you should pass on all the parameters required for a particular type of entity. Below we will go into more details per entity type.
KYC API for Individual Verification with Electronic Safe Harbour (Australia)
Access and review the API Documentation for using the KYC API for verifying individuals in Australia at https://docs.bronid.com/kyc-aus-individual. Here you will find the documentation that specifies the required fields, validation requirements for the data entry and the structure of the API call.
The form you will design must collect at the minimum the full name, date of birth and the residential address of the individual. In addition, we strongly recommend that you have fields to collect ID documents. Although collection of ID documents is not mandatory, it significantly improves the match rate and with that the chances to get a verified result. You can make the collection of at least one ID document mandatory in your forms, however this is optional.
When running an identity verification of an individual (KYC) with bronID, you can get two types of results:
- Verified: the individual’s identity details match 2 databases and with that achieve electronic Safe Harbour; or
- Rejected: the individual’s identity details match 2 databases and with that achieve electronic Safe Harbour.
Below is a flowchart of the ID potential ID verification states (statuses).
If an individual cannot be verified on the first attempt, ideally they will be allowed to resubmit the information either by correcting the data or adding an additional ID document to improve the match rate. Ensure that you limit the number of attempts allowed to limit your cost.
To test the ID verification in the test environment, you must follow the test scenarios provided by bronID below.
To achieve any of the outcomes in the bronID test environment, Verified or Rejected, you must follow the scenarios described in the table below:
Get a Verified Result Without Documents
In a nutshell, to get a verified result you need to put "OK" or "PEP" as the middle name. Using "OK" will return a verified result and the person will not match any of the PEPs and Sanctions databases. If you use "PEP" as the middle name, the person will be verified but they will return a positive match on the PEPs and Sanctions databases.
Examples:
- Verified (does not appear on a watchlist): John OK Citizen, 10/10/1987, 125A York Street, SYDNEY NSW 2000
- Verified (appears on a watchlist): John PEP Citizen, 10/10/1987, 125A York Street, SYDNEY NSW 2000
Get a Verified Result Using Documents
If you want to use documents in the test scenarios then you must use the values provided in the table above. In this case you should not add the keywords "OK" or "PEP" in the middle name.
Example:
- Verified (does not appear on a watchlist): John Citizen, 10/10/1987, 125A York Street, SYDNEY NSW 2000, Passport Number: A1111111 and Driver's Licence Number: 11111111, Driver's Licence Card Number: 1111111111
Submitting images as part of the API call is optional, however we suggest that you do so if you want to have images of the documents for your customers. If you upload images of the ID documents, they will be available in the bronID portal.
Get a Rejected Result Using Documents
To get a rejected result, you can use any value in the first, middle or last name, but do not use "OK" or "PEP" as a middle name.
Examples:
- Rejected: John Peter Citizen, 10/10/1987, 125A York Street, SYDNEY NSW 2000
Example API request
Below is an example API request showing the required parameters based on the instructions above.
You can also have a look at our runnable examples and experiment with the input parameters, and review the response: https://docs.bronid.com/kyc-aus-individual
1// api endpoint
2const apiEndpoint = 'https://dev.bronid.com/verify';
3
4// request body
5const kycData = {
6 "metadata_version": "4",
7 "metadata_serviceUid": "XL7ULiU6B4QE9Y2iWFZnhtMDKFN2",
8 "metadata_secretKey": "api_sec_NJAtNcRtUrPlf7xYDrMNP9URI-ZfN314",
9 "metadata_userId": "ID-1276-567-001",
10 "metadata_tags": ["Virtual Cards", "GROUP A"],
11
12 "type": "individual",
13 "fields": {
14 "country": "AUS",
15 "firstName": "Jane",
16 "middleName": "PEP",
17 "lastName": "Citizen",
18 "dateOfBirth": "20/10/1980",
19 "unitNumber": "1",
20 "streetNumber": "95",
21 "streetName": "Lennox",
22 "streetType": "Street",
23 "suburb": "CASINO",
24 "postcode": "2470",
25 "state": "NSW",
26 "email": "email@gmail.com"
27 }
28}Example API response (webhooks)
Once your request is sent to bronID, you will receive back one or multiple webhooks depending on your screening rules configuration.
The first webhook will include the individual's verification status and verification score. An verification score of 100 or higher and a status of "verified" indicates that the submitted individual has matched two databases and is considered verified.
If the status is "rejected", this means the person could not be verified due to insufficient database matches. In this case, the customer should:
- Check if their entered data is correct
- If the data is correct, provide additional ID documents to increase their chances of matching two databases
1bronId API response: {
2 "name": "Jane PEP Citizen",
3 "verificationStatus": "verified",
4 "verificationScore": 200,
5 "verificationUuid": "9fc6ff3e-1b38-4350-a568-0f29e62b4710",
6 "submissionId": "47f87305-cf3c-46d7-bcd5-2ef736e1998d",
7 "trace": "9fc6ff3e-1b38-4350-a568-0f29e62b4710",
8 "submissionStatus": "submitted",
9 "userId": "ID-1276-567-001",
10 "timestamp": 1736320286,
11 "inWatchLists": [],
12 "outOfWatchLists": []
13}If your screening rules are configured to automatically check for PEPs, Sanctions and/or Negative Media at the time of verification, bronID will send you an additional webhook. This webhook will contain both the calculated IDV Risk and the screening results.
KYC API for Individual Verification with Electronic Safe Harbour (Other Countries)
Integrating the API for countries other than Australia follows the same logic as the KYC API for Australia, with the only difference being the specific fields that can be submitted for each country which are different per country due to existence of different document types.
To learn about the specific fields, review the API documentation for each country using the links below:
- New Zealand: https://docs.bronid.com/kyc-nzl-individual
- USA: https://docs.bronid.com/kyc-usa-individual
- China: https://docs.bronid.com/kyc-chn-individual
- Group 1 (Austria, Belgium, Switzerland, Germany, France, United Kingdom, Netherlands, Norway): https://docs.bronid.com/kyc-default-individual
- Group 2 (Brazil, Spain, Mexico): https://docs.bronid.com/kyc-group-2-individual
- Group 3 (Canada, Denmark, Italy, Sweden): https://docs.bronid.com/kyc-group-3-individual
The API response for international verifications follows the same format as Australian verifications. You will receive:
- Verification results via webhook with the same format as shown in the Australian examples
- Screening results (if configured) delivered through webhooks in the same structure
All webhook formats and response patterns demonstrated in the Australian examples apply consistently across all supported countries.
KYC API for Organisation Verification (Australia)
With the bronID API, you can perform verification on all entity types including companies, trusts, SMSFs, associations, government bodies, and more.
Access and review the API Documentation for using the KYC API for verifying organisations in Australia. Use the top left menu to change the entity types in the documentation page and review the documentation for each organisation type. Here you will find the documentation that specifies the required fields, validation requirements for the data entry and the structure of the API call.
You should use this documentation to design your forms for data collection from the customer. Each entity type will require different fields and documents to be provided and uploaded, so it is important that you review the documentation per organisation type. We strongly suggest that you implement only the entity types and countries that you reasonably expect customers for to reduce decision fatigue by the customer and reduce confusion.
Although you are free to design your forms as you would like, we recommend that you go to the bronID Portal and have a look at the bronID data collection forms per entity type and use that as a template or inspiration to design your own forms.
When running an identity verification of an organisation with bronID, you can get four types of results:
- Pending: This means that the KYB submission has been received and is waiting on bronID to perform the verification process.
- Info: The "Info" status means that bronID requires you to provide additional information such as personal details of the listed UBOs or upload a document (e.g., Deed of Variation for the Change of Trust Name, Unit Register, etc.). bronID will tell you exactly what action needs to be performed.
- Verified: The organisation is verified and no further action is needed.
- Rejected: The organisation could not be verified. Often the reason why the organisation cannot be verified is because it is submitted as incorrect entity type, or the submitted name or business number does not exist in the relevant government registers.
Below is a flowchart of the potential ID verification states (statuses).
To test the ID verification in the test environment, you must follow the test scenarios provided by bronID below to get the desired statuses.
Examples:
- Verified (Name starts with "Pass"): Entity name = Pass Corp Pty Ltd
- Info (Name starts with "Info"): Entity name = Info Corp Pty Ltd
- Rejected (Name starts with "Fail"):Entity name = Fail Capital Limited
Example API request
Below are provided examples of API request showing the required parameters based on the instructions above. Note that the API request parameters differ for each entity type (e.g., Private Company, Public Company, Unregulated Trust, Association, etc.). To see the different API request parameters which are required or optional, use the top left menu in the documentation page: https://docs.bronid.com/kyc-aus-private-company
In general, there are two main groups of parameters that you need to submit:
1. Fields: This is a list of parameters related to the entity such as the entity number, name and address, as well as documents that need to be uploaded for a particular entity type (e.g., a trust deed).
2. Stakeholders: These are different roles within the entity that may be individuals or organisations (e.g., shareholders, trustees, beneficiaries, directors, etc.). Some stakeholders are required to be submitted in the initial request (e.g., public officer or trustee), while others are not. If a stakeholder has not been submitted but is required for the verification of the organisation, they will be requested in the follow-up Info request. Note that some stakeholders can be entities (e.g., a private company) and their details need to be submitted in accordance with the format for that particular entity type.
TIP: Do not submit the same stakeholder in different roles (e.g. director and shareholder) if applicable, as bronID will map out all relevant roles and this will reduce the cost of the verification.
EXAMPLE 1: Private Company with 2 shareholders (returns “Verified” result)
Documentation: https://docs.bronid.com/kyc-aus-private-company
In this example, we will submit a Private Company with 2 shareholders. We will create a scenario where the private company will return a verified result in the test environment as the name will start with "Pass" (i.e., "Pass Company Pty Ltd"). Also, the shareholders will be verified as their middle names will be submitted as "ok" in accordance with the test scenario guidelines.
1// api endpoint
2const apiEndpoint = 'https://dev.bronid.com/verify';
3
4// request body
5const kycData = {
6 "metadata_version": "4",
7 "metadata_serviceUid": "XL7ULiU6B4QE9Y2iWFZnhtMDKFN2",
8 "metadata_secretKey": "api_sec_NJAtNcRtUrPlf7xYDrMNP9URI-ZfN314",
9 "metadata_userId": "UI-5267345-6287456-7",
10 "metadata_tags": ["LOANS", "Investment Department"],
11
12 "type": "privateCompany",
13 "fields": {
14 "country": "AUS",
15 "acn": "123456789",
16 "abn": "16123456789",
17 "name": "Pass Company Pty Ltd",
18 "registeredOffice": "125 York Street, SYDNEY NSW 2000",
19 "principalPlaceOfBusiness": "250 York Street, SYDNEY NSW 2000",
20 "companyExtract": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg=="
21 },
22 "stakeholders": [
23 {
24 "type": "individual",
25 "role": "shareholders",
26 "fields": {
27 "firstName": "Jane",
28 "middleName": "ok",
29 "lastName": "Citizen",
30 "dateOfBirth": "20/10/1980",
31 "unitNumber": "1",
32 "streetNumber": "95",
33 "streetName": "Lennox",
34 "streetType": "Street",
35 "suburb": "CASINO",
36 "postcode": "2470",
37 "state": "NSW",
38 "email": "email@gmail.com",
39 "country": "AUS"
40 }
41 },
42 {
43 "type": "individual",
44 "role": "shareholders",
45 "fields": {
46 "firstName": "Dave",
47 "middleName": "ok",
48 "lastName": "Citizen",
49 "dateOfBirth": "20/10/1980",
50 "unitNumber": "1",
51 "streetNumber": "95",
52 "streetName": "Lennox",
53 "streetType": "Street",
54 "suburb": "CASINO",
55 "postcode": "2470",
56 "state": "NSW",
57 "email": "email@gmail.com",
58 "country": "AUS"
59 }
60 }
61 ]
62}
Response
The API response includes verification results for both the company and its stakeholders. For the company ("Pass Company Pty Ltd"), it provides a verification status, a unique verification UUID, timestamp, user ID, and submission status. For each stakeholder, the response contains their name, role, verification status, verification score (200 in this case), an IDV risk score (rated as "Low"), unique identifiers (verification UUID, submission ID, and trace), submission status, timestamp, and watchlist check results (shown as empty arrays for both included and excluded lists) as the results from the PEPs and Sanctions screening and the Negative Media screening will be sent to you in a follow up webhook. This structured response enables tracking of both the overall company verification and individual stakeholder verifications within a single request.
1bronId API response: {
2 "name": "Pass Company Pty Ltd",
3 "verificationStatus": "verified",
4 "verificationUuid": "abd38237-b095-45f4-9867-c4b157600595",
5 "timestamp": 1736837944,
6 "userId": "UI-5267345-6287456-7",
7 "submissionStatus": "submitted",
8 "stakeholders": [
9 {
10 "name": "Jane ok Citizen",
11 "role": "shareholders",
12 "id": "67a97e30-b8b4-4d73-9c38-07e4f94ecf1c",
13 "verificationStatus": "verified",
14 "verificationScore": 200,
15 "idvRiskScore": {
16 "description": "Low"
17 },
18 "verificationUuid": "d4246ab1-8070-4a23-9a19-b9b2725704e7",
19 "submissionId": "abd38237-b095-45f4-9867-c4b157600595",
20 "trace": "d4246ab1-8070-4a23-9a19-b9b2725704e7",
21 "submissionStatus": "submitted",
22 "timestamp": 1736837947,
23 "inWatchLists": [],
24 "outOfWatchLists": []
25 },
26 {
27 "name": "Dave ok Citizen",
28 "role": "shareholders",
29 "id": "542f9db6-fb80-49db-916b-6a554a4644d9",
30 "verificationStatus": "verified",
31 "verificationScore": 200,
32 "idvRiskScore": {
33 "description": "Low"
34 },
35 "verificationUuid": "26c78cde-4666-48fa-95bf-49199d5e324f",
36 "submissionId": "abd38237-b095-45f4-9867-c4b157600595",
37 "trace": "26c78cde-4666-48fa-95bf-49199d5e324f",
38 "submissionStatus": "submitted",
39 "timestamp": 1736837948,
40 "inWatchLists": [],
41 "outOfWatchLists": []
42 }
43 ],
44 "submissionId": "abd38237-b095-45f4-9867-c4b157600595",
45 "trace": "abd38237-b095-45f4-9867-c4b157600595"
46}
If your screening rules are configured to automatically check for PEPs, Sanctions and/or Negative Media at the time of verification, bronID will send you an additional webhook. This webhook will contain both the calculated IDV Risk and the screening results.
EXAMPLE 2: Unregulated Trust with a with corporate trustee and one beneficiary (returns “Info” result)
Documentation: https://docs.bronid.com/kyc-aus-unregulated-trust
In this example, we will submit an Unregulated Trust with one corporate trustee (Private Company) and one individual beneficiary. We will create a scenario where the submission will return an Info result in the test environment as the name will start with "Info" (i.e., "Info Family Trust"). Also, the beneficiary will be verified as their middle name will be submitted as "OK" in accordance with the test scenario guidelines.
1// api endpoint
2const apiEndpoint = 'https://dev.bronid.com/verify';
3
4// request body
5const kycData = {
6 "metadata_version": "4",
7 "metadata_serviceUid": "XL7ULiU6B4QE9Y2iWFZnhtMDKFN2",
8 "metadata_secretKey": "api_sec_NJAtNcRtUrPlf7xYDrMNP9URI-ZfN314",
9 "metadata_userId": "CL-5463-6473-3562",
10 "metadata_tags": ["Virtual Cards", "ABC"],
11
12 "type": "unRegulatedTrust",
13 "fields": {
14 "country": "AUS",
15 "name": "Info Family Trust",
16 "abn": "16123456789",
17 "unRegulatedTrustType": "familyTrust",
18 "registeredOfficeRequired": "125 York Street, SYDNEY NSW 2000",
19 "trustDeed": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg=="
20 },
21 "stakeholders": [
22 {
23 "type": "individual",
24 "role": "beneficiaries",
25 "fields": {
26 "firstName": "Jane",
27 "middleName": "ok",
28 "lastName": "Citizen",
29 "dateOfBirth": "20/12/1982",
30 "unitNumber": "1",
31 "streetNumber": "95",
32 "streetName": "Lennox",
33 "streetType": "Street",
34 "suburb": "CASINO",
35 "postcode": "2470",
36 "state": "NSW",
37 "email": "email@gmail.com",
38 "country": "AUS"
39 }
40 },
41 {
42 "type": "privateCompany",
43 "role": "trustee",
44 "fields": {
45 "country": "AUS",
46 "acn": "111222333",
47 "name": "EXAMPLE TRUSTEE PTY LTD",
48 "registeredOffice": "125 York Street, SYDNEY NSW 2000",
49 "principalPlaceOfBusiness": "250 York Street, SYDNEY NSW 2000"
50 }
51 }
52 ]
53}
Response
The API response includes verification details for both the trust and its stakeholders. The response contains the trust's name ("Info Family Trust"), its verification status ("info"), a unique verification UUID, timestamp, user ID, and submission status ("incomplete"). For each stakeholder, it provides detailed verification information including their name, role, ID, verification status, verification score, IDV risk score, submission ID, and submission status.
bronId API response: {
"name": "Info Family Trust",
"verificationStatus": "info",
"verificationUuid": "68b183eb-f50e-4c8c-83dd-ed024bd86459",
"timestamp": 1736838562,
"userId": "CL-5463-6473-3562",
"submissionStatus": "incomplete",
"stakeholders": [
{
"name": "Jane ok Citizen",
"role": "beneficiaries",
"id": "869bc9ea-691b-4c31-97de-68b182e59f76",
"verificationStatus": "verified",
"verificationScore": 200,
"idvRiskScore": {
"description": "Low"
},
"verificationUuid": "4fa96ce7-7461-4220-8871-ad3a7f1f9ae3",
"submissionId": "68b183eb-f50e-4c8c-83dd-ed024bd86459",
"trace": "4fa96ce7-7461-4220-8871-ad3a7f1f9ae3",
"submissionStatus": "submitted",
"timestamp": 1736838565,
"inWatchLists": [],
"outOfWatchLists": []
},
{
"name": "EXAMPLE TRUSTEE PTY LTD",
"role": "trustee",
"id": "937cdf0b-61fe-4177-bf49-8168eb3114f5",
"verificationStatus": "pending",
"verificationScore": 0,
"idvRiskScore": {
"description": "Undefined"
},
"submissionId": "68b183eb-f50e-4c8c-83dd-ed024bd86459",
"submissionStatus": "submitted"
}
],
"submissionId": "68b183eb-f50e-4c8c-83dd-ed024bd86459",
"trace": "68b183eb-f50e-4c8c-83dd-ed024bd86459"
}If your screening rules are configured to automatically check for PEPs, Sanctions and/or Negative Media at the time of verification, bronID will send you an additional webhook. This webhook will contain both the calculated IDV Risk and the screening results.
EXAMPLE 3: SMSF a with an individual trustee and one beneficiary (returns “Verified” result)
Documentation: https://docs.bronid.com/kyc-aus-smsf
In this example, we will submit an SMSF with one individual trustee and one individual beneficiary. We will create a scenario where the submission will return a verified result in the test environment as the name will start with "Pass" (i.e., "PASS SUPER"). Also, the trustee and beneficiary will be verified as their middle name will be submitted as "OK" in accordance with the test scenario guidelines.
1// api endpoint
2const apiEndpoint = 'https://dev.bronid.com/verify';
3
4// request body
5const kycData = {
6 "metadata_version": "4",
7 "metadata_serviceUid": "XL7ULiU6B4QE9Y2iWFZnhtMDKFN2",
8 "metadata_secretKey": "api_sec_NJAtNcRtUrPlf7xYDrMNP9URI-ZfN314",
9 "metadata_userId": "CL-73-7387-74837-00",
10 "metadata_tags": ["INVESTMENT", "GOG FUNDS"],
11
12 "type": "smsf",
13 "fields": {
14 "country": "AUS",
15 "name": "PASS SUPER",
16 "abn": "11122233355",
17 "registeredOffice": "125 York Street, SYDNEY NSW 2000",
18 "uploadTrustDeed": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg=="
19 },
20 "stakeholders": [
21 {
22 "type": "individual",
23 "role": "beneficiaries",
24 "fields": {
25 "firstName": "Jane",
26 "middleName": "ok",
27 "lastName": "Citizen",
28 "dateOfBirth": "20/12/1982",
29 "unitNumber": "1",
30 "streetNumber": "95",
31 "streetName": "Lennox",
32 "streetType": "Street",
33 "suburb": "CASINO",
34 "postcode": "2470",
35 "state": "NSW",
36 "email": "email@gmail.com",
37 "country": "AUS"
38 }
39 },
40 {
41 "type": "individual",
42 "role": "trustee",
43 "fields": {
44 "firstName": "Dave",
45 "middleName": "ok",
46 "lastName": "Citizen",
47 "dateOfBirth": "20/12/1982",
48 "unitNumber": "1",
49 "streetNumber": "95",
50 "streetName": "Lennox",
51 "streetType": "Street",
52 "suburb": "CASINO",
53 "postcode": "2470",
54 "state": "NSW",
55 "email": "email@gmail.com",
56 "country": "AUS"
57 }
58 }
59 ]
60}
Response
The API response for the SMSF verification will provide the verification results for both the fund and its stakeholders. The main fund "PASS SUPER" is marked as "verified" with its unique verification UUID, timestamp, and submission details. For the stakeholders, which include Jane Citizen as a beneficiary and Dave Citizen as a trustee, each has received a verification score of 200 with an IDV risk score rated as "Low".
1bronId API response: {
2 "name": "PASS SUPER",
3 "verificationStatus": "verified",
4 "verificationUuid": "d6b51288-e038-410f-8039-af61bfdcfedd",
5 "timestamp": 1736838960,
6 "userId": "CL-73-7387-74837-00",
7 "submissionStatus": "submitted",
8 "stakeholders": [
9 {
10 "name": "Jane ok Citizen",
11 "role": "beneficiaries",
12 "id": "99ca27f2-791f-4cc9-b249-f1fc6ea2dc78",
13 "verificationStatus": "verified",
14 "verificationScore": 200,
15 "idvRiskScore": {
16 "description": "Low"
17 },
18 "verificationUuid": "8461660e-0a9c-4d23-8f6f-9b658c0d583f",
19 "submissionId": "d6b51288-e038-410f-8039-af61bfdcfedd",
20 "trace": "8461660e-0a9c-4d23-8f6f-9b658c0d583f",
21 "submissionStatus": "submitted",
22 "timestamp": 1736838965,
23 "inWatchLists": [],
24 "outOfWatchLists": []
25 },
26 {
27 "name": "Dave ok Citizen",
28 "role": "trustee",
29 "id": "28a38bb9-c3c4-4c19-a1cb-101fbc91edfa",
30 "verificationStatus": "verified",
31 "verificationScore": 200,
32 "idvRiskScore": {
33 "description": "Low"
34 },
35 "verificationUuid": "3dd9e214-8f55-4484-bf82-9c3c095446b7",
36 "submissionId": "d6b51288-e038-410f-8039-af61bfdcfedd",
37 "trace": "3dd9e214-8f55-4484-bf82-9c3c095446b7",
38 "submissionStatus": "submitted",
39 "timestamp": 1736838965,
40 "inWatchLists": [],
41 "outOfWatchLists": []
42 }
43 ],
44 "submissionId": "d6b51288-e038-410f-8039-af61bfdcfedd",
45 "trace": "d6b51288-e038-410f-8039-af61bfdcfedd"
46}
If your screening rules are configured to automatically check for PEPs, Sanctions and/or Negative Media at the time of verification, bronID will send you an additional webhook. This webhook will contain both the calculated IDV Risk and the screening results.
IMPORTANT TIP: Clean data via the “Entity lookup” endpoint (Australia and New Zealand)
Documentation: https://docs.bronid.com/entity-lookup
We strongly advise that when you create the onboarding flow for your customers, you enforce checking that the number, name and type of the entity they want to submit is correct. bronID provides a free API endpoint to do so. You should use this API endpoint to make these checks and alert the customer if they are:
- Trying to submit an entity number that does not exist
- Submitting a number that does not correspond with the entity name
- Making a typo in the entity details
- Trying to submit the entity under an incorrect entity type
By using this API endpoint you can provide a real-time feedback to your customer and significantly improve the match rate.
