Process a request for ownership details for an Australian organisation ONLY.
See below for more general international queries.
At a minimum, you just need to supply an ACN or ABN and we can retrieve the rest. You also have the option of supplying company name, type (as per ABR types) and both ABN/ACN and we’ll attempt to verify that that data matches what is on record before attempting any further verification and validation.
KYC/AML for a selection of entities associated with an organisation and/or the organisation itself can optionally be run, but not by default. To enable KYC/AML checks one or more entity categories must be provided. If such a list of entity categories is given then default checks based on configuration will be run for those categories. If a check type is also provided in the request then that type will be used for entities representing individual entities, and the AML subset of that check will be used for organisations if any. Specifying a check type without an entity category will result in an error.
NOTE: A 202 ACCEPT response will be returned if there are full ownership details to be retrieved or there is entity verification requested. In this case results will be pushed using the Push Notification API below and you will be able to retrieve the results using the Retrieve API.
If only basic ownership (profile only) is requested with no entity verification, then the result will be a 200 OK.
More details on how to use this API and interpret the results can be found here:
https://docs.frankieone.com/docs/australian-business-function-overview
Customer ID issued by Frankie Financial. This will never change. Your API key, which is mapped to this identity, will change over time.
If, as a Frankie Customer, you are acting on behalf of your own customers, then you can populate this field with a Frankie-assigned ID.
Note: If using a CustomerChildID, you will also need a separate api_key for each child.
Any documents, checks, entities that are created when this field has been populated will now be tied to this CustomerID + CustomerChildID combination. Just as Customers cannot see data created by other Customers, so too a Customer’s Children will not be able to see each other’s data.
A Customer can see the documents/entities and checks of all their Children.
Open string that can be used to define the “channel” the request comes in from. It can potentially be used in routing and risk calculations upon request. Default values that can be used are:
Any alphanumeric string is supported though. Anything over 64 characters will be truncated.
When creating a new check, we need to define the checks we wish to run. If this parameter is not supplied then the check will be based on a configured check type for each entity category.
The checkType is make up of a comma separated list of the types of check we wish to run.
The order is important, and must be of the form:
Entity Checks - One of:
ID Checks - One of:
Fraud Checks - One or more of:
PEP Checks - One of:
Pre-defined combinations (deprecated):
Custom:
This will allow you to set the minimum number of matches for:
This allows for alternatives to the “standard” two_plus or one_plus (note, these can be overridden too).
Profile:
The profile to use will be taken from the entity.entityProfile field if set, or be run through a set of configurable rules to determine which one to use.
Profiles act a little like the Pre-defined combinations above in that they can map to a defined list. But they offer a lot more besides, including rules for determining default settings, inbuild data aging and other configurable features. They also allow for a new result set top be returned that provides a more detailed and useful breakdown of the check/verification process.
Entity Profiles are the future of checks with Frankie Financial.
A comma separated list that specifies the categories of entities associated with the target organisation that will be checked.
The result level allows you to specify the level of detail returned for the entity check. You can choose summary or full.
Should a validation check be run before the ownership query. The default is specified via configuration. The validation checks to see if the provided organisation is suitable for an ownership query by looking for the ACN in public data sources. Options are:
The type of human readable report, if any, to generate based on the ownership query results. Options are:
Name of configured preset query parameters to use. Any individual parameters provided in the request will override the same parameter in the configured preset.
If set to true, historical ownership data will be requested.
If set to true, a full UBO report will not be requested. Note: This param is deprecated, use ownershipMode instead.
Do not load the named result objects from cache, but force them to be retrieved from an approproate service, if and when they are required. Options are:
Define the ownership mode you wish to run.
Valid ownership modes are:
Describes all of the data being used to verify an entity.
A list of manual associations you wish to make with the business to be queried.
If your configuration supports this (ask your customer success representative), you can potentially compare any UBOs or office holders you supply against those found through local registries.
This is what you will find in the payload of a retrieved response should the ownership query succeed, or you’re querying the past checks for a given business.
NOTE: When requesting the initial report, you will only ever receive a 202 response.
Used to set additional information flags for this response.
Batch identifier for the KYC/AML check results if any.
The results of KYC/AML check on a organisation with a prior ownership query. This will be retrived via GET /retrieve/response/{requestId} after you receive a notification that the results are ready.
If an ownership result is provided in this response then this is the date and time the service provided that result.
Unique identifier for the ownership check.
The positive result of a report generation request if any.
Unique identifier for every request. Can be used for tracking down answers with technical support.
Uses the ULID format (a time-based, sortable UUID)
Note: this will be different for every request.