FrankieOne Pricing for Mortgage Brokers 2026

FrankieOne pricing starts with a sales enquiry for the verification service your brokerage needs. Its public Contact Sales route leads to a demo request, so procurement centres on a written scope and commercial offer. FrankieOne suits brokerages that need configurable identity and screening workflows and have someone to own their implementation.

For a small brokerage needing one lender-accepted identity check, a ready-made service can be easier to operate. Separate the identity result you need from the software connection you would have to maintain.

FrankieOne Pricing and Procurement

As at 3 October 2026, FrankieOne’s public sales route is its Book a Demo form. Describe your Australian borrower workflow and the checks you want to buy. The signed offer must identify the billing unit and included services before you can compare it with a per-check alternative.

A workable procurement schedule covers the following items. These are contract requirements to request, not advertised FrankieOne inclusions.

Item	What the offer needs to specify	Why it changes the decision
Currency and tax	Australian-dollar or other currency billing, and whether goods and services tax (GST) is included	Prevents comparison of different tax or currency bases
Checks and providers	Named checks, selected data providers and supported document jurisdictions	Defines what each purchased verification actually does
Chargeable activity	Treatment of completed checks, retries, additional screening and ongoing monitoring	Application counts alone do not describe all activity
Volume and commitment	Forecast volume, minimum commitment and any agreed tiers	Determines whether low-volume use is economical
Users and environments	Portal users, testing access and production access	Defines who can operate the workflow and where
Implementation	Configuration, development, training and responsibility for changes	Separates supplier charges from your own delivery work
Support and contract	Support coverage, escalation, renewal, exit and evidence export	Determines who handles a failed check and the cost of leaving

FrankieOne’s API documentation distinguishes testing from user acceptance testing (UAT) and production. UAT and production access are restricted to contracted customers. A testing environment’s availability does not establish a free production plan or an included implementation service.

Treat provider choice and country coverage as scope decisions. FrankieOne connects multiple vendors and allows configured checks to be selected. The Australian offer must state how those choices affect charges.

Do not assume a single borrower fee covers every document, jurisdiction or verification step.

For example, a hypothetical brokerage forecasts one identity workflow per new borrower plus occasional corrections and screening referrals. Its budget needs the agreed chargeable checks and staff review time. A quote based only on settled loans would omit applications that never settle.

Identity, AML and Consent Workflow

FrankieOne combines identity verification with configured anti-money laundering (AML) screening, but each check answers a different question. Know your customer (KYC) verification checks supplied identity information. Screening identifies potential matches that need interpretation under your policies.

FrankieOne’s Australian documentation describes government-document checks and database matching configurations. It distinguishes a ruleset, which sets matching requirements, from a recipe, which combines checks into a workflow. Names such as Safe Harbour describe configurations, not a guarantee that every brokerage’s obligations are satisfied.

Check	What it contributes to a borrower file	Configuration boundary
Government document verification	Matches document details through the Document Verification Service (DVS)	Use the supported document and field requirements for that route
Database identity matching	Checks supplied identity details against selected datasets	The matching ruleset and available sources determine the result
Document and biometric checks	Examines document images and compares a selfie with identity evidence	Requires the selected capture service and provider configuration
Sanctions and politically exposed person (PEP) screening	Returns possible matches for review	Match filters and the chosen screening workflow affect returned records
Adverse media and fraud checks	Adds configured risk signals to the review	Include these in the purchased workflow where needed

A DVS match and a selfie comparison are separate checks. FrankieOne’s customer guidance says DVS checking does not require physical identity-document photos. Adding image capture or biometrics therefore changes collection and handling requirements.

A Synthetic Borrower Onboarding Case

Consider a fictional borrower, Sam, applying through an Australian brokerage. This example describes a workflow design, not observed FrankieOne results.

1. The brokerage identifies the lender’s accepted identity process and its own collection requirements. It gives Sam a notice explaining the purpose and intended disclosures.
2. Sam supplies the identity fields required for that process. The brokerage records the applicable consent and notice version before sending data for checks.
3. If the selected route requires document images and a selfie, Sam completes the configured capture flow. FrankieOne’s documented provider flow sends captured material to the identity provider.
4. The brokerage’s backend starts the configured verification process. FrankieOne collects provider results and makes them available through its portal or API.
5. An authorised reviewer resolves any referral. The brokerage stores the report and review decision with the correct borrower file, then hands over the lender-required evidence.

For entities covered by the Australian Privacy Principles (APPs), sensitive-information collection generally requires consent unless an exception applies. A collection notice alone does not supply consent. The Office of the Australian Information Commissioner’s privacy principles govern collection and notice separately.

The brokerage remains responsible for its legal duties and lender requirements. The Australian Transaction Reports and Analysis Centre’s designated-services guidance makes the activity performed relevant to anti-money laundering and counter-terrorism financing (AML/CTF) coverage. Buying screening software does not determine your reporting-entity status.

Keep property-file verification of identity requirements distinct from a database match. The evidence must satisfy the process for which you are collecting it.

Implementation and Exception Handling

A direct FrankieOne implementation needs technical ownership of the connection and operational ownership of the resulting referrals. Its unified application programming interface (API) provides access to configured verification services. Orchestration is the choice and sequence of checks behind that connection.

Route	How it works	Who owns the brokerage’s work
Direct API	Your backend submits data and processes returned results	Your developer owns credentials, error handling and file mapping
OneSDK or configured capture interface	A software development kit (SDK) supports the customer-facing capture flow	Your implementation team owns deployment and consent presentation
FrankieOne portal	Authorised staff review entity and workflow information	Your administrator owns permissions and your reviewer owns decisions
Official connector in another platform	A documented platform connection supplies the agreed service	The platform owner defines supported actions and support boundaries
Third-party implementation	An integrator builds and maintains your connection	The contract must assign development, security and incident responsibilities

For a platform-delivered service, select the offering on the platform’s actual supported workflow. An API capability alone does not establish an official connector to your broker software. Require the provider agreement to identify the checks supplied and who receives the evidence.

Design exception handling before processing live borrowers. The following actions are brokerage controls, not claims that FrankieOne automatically decides these cases.

Outcome	Review action	Evidence to retain
No match	Compare entered details with the supplied document, then use the approved correction or alternate verification route	Original result and the reason for the next check
Partial match	Identify the unmatched field and obtain the evidence needed to resolve it	Field-level outcome and reviewer explanation
Screening referral	Compare the potential match with the borrower using available identifying details	Match source and the review decision
Suspected fraud	Escalate through your compliance process and control further processing	Restricted evidence and escalation history
Service unavailable	Keep the check pending and use the agreed retry or approved fallback	Request reference, time and service error

FrankieOne documents separate workflow states, including unfinished checks and outcomes needing attention. Its audit documentation distinguishes connector errors from matching results. A service failure cannot establish that a borrower’s identity failed verification.

FrankieOne lists help@frankieone.com for technical and general support and onboarding@frankieone.com for implementation guidance. Its customer guidance lists 1800 325 117 for urgent production issues. Route incidents through the support terms agreed for your account.

Evidence, Security and Retention

FrankieOne provides check results and audit information, while your brokerage must preserve the evidence needed for its borrower file. An overall pass badge does not describe every check or replace the review record.

Its workflow documentation identifies an event ID for each execution and check summaries naming the data source. Audit records cover entity changes and workflow activity, including manual status changes. The audit report can be downloaded as a PDF.

The Individual Verification Report is a snapshot of the latest checks for an individual. Its documented contents include identity details and summaries of KYC, document, biometric and AML checks. FrankieOne says portal report generation requires Customer Support activation, so include that feature in the implementation scope.

Screening results can contain match criteria and underlying source references. Preserve the source details needed to explain a referral, along with who reviewed it. A later report showing the latest results cannot replace the earlier decision record by itself.

FrankieOne publicly states that it has ISO 27001:2022 certification and a System and Organization Controls (SOC) 2 Type 2 attestation. Its security page describes role-based portal permissions, multi-factor authentication and single sign-on. Those controls support supplier assessment but do not remove your responsibility for staff access.

The privacy policy effective 15 May 2026 states that FrankieOne stores personal information it holds on Amazon Web Services servers in Australia. It also permits international disclosures, including matching against overseas organisations. Australian storage must therefore be considered alongside the selected provider’s processing route.

FrankieOne’s policy describes purpose-based retention and additional legal or business grounds for keeping information. It does not set one universal borrower-file retention period. Your contract needs an account-specific retention schedule and an exit process that preserves required records before deletion.

For an APP entity, APP 11 requires reasonable security steps and, subject to its exceptions, destruction or de-identification when information is no longer needed. APP 8 addresses overseas disclosure. Apply these requirements to the whole borrower document collection process, including copies exported into your own systems.

FrankieOne Fit and Alternatives

Choose FrankieOne when your brokerage needs configurable checks across providers and has an implementation team and a review process. Its combination of orchestration and event-level evidence suits a workflow that needs more control than a single identity check.

A ready-made identity service fits better when the central requirement is one defined, lender-accepted process and staff need to operate it without maintaining a custom connection. An existing broker-platform service fits when it already supplies the required checks and usable file evidence. Compare those routes against the same borrower process, not the number of providers each advertises.

Brokerage requirement	Appropriate route
Multiple configured checks with technical ownership	FrankieOne direct implementation or a contracted integrator
A small number of standard checks with minimal development	Ready-made verification service accepted for the required process
Identity checking already supplied through broker software	Existing platform service with defined evidence and support responsibilities
A document or jurisdiction outside the configured coverage	Another accepted provider or the lender’s approved manual process
A borrower who cannot complete the capture journey	Approved assisted or manual verification route
Evidence export or support unsuitable for the file requirements	A service whose contract meets those requirements

Keep an alternate route for unsupported documents and service interruptions. Manual fallback must follow the applicable lender or legal process and retain its own evidence. Choose the service that delivers your required verification and review record within an operating model your brokerage can maintain.