Overview
This guide covers FrankieOne’s KYC solution for Australian banking, designed to support AUSTRAC risk-based customer due diligence requirements (current framework aligned with ‘2+2’ expectations, designed to evolve with upcoming AML/CTF reforms in Australia). This use case illustrates how a configurable risk-based onboarding flow can support both current AUSTRAC expectations and the direction of upcoming AML/CTF reforms in Australia.Summary
Available Workflows
| Workflow | CDD Tier | Purpose | When to Use |
|---|---|---|---|
AUS-Risk-CDD-Email-Phone | All | Risk-based orchestration | Recommended - Automatically routes based on risk signals |
AUS-Basic3V-TwoPlusID | Simplified | Streamlined verification | Low-risk customers, established relationships |
AUS-Advanced1V-IDOnly | Standard | Government ID verification | Medium-risk customers, most new accounts |
AUS-Advanced3V-TwoPlusID | Enhanced (EDD) | Full enhanced verification | High-risk customers, PEPs, high-value products |
Risk-Based Orchestration: AUS-Risk-CDD-Email-Phone
| Risk Level | CDD Tier | Routed To | Checks Included |
|---|---|---|---|
| Low | Simplified | AUS-Basic3V-TwoPlusID | DVS, dual credit bureau, electoral roll, PEP/sanctions |
| Medium | Standard | AUS-Advanced1V-IDOnly | Government ID verification, PEP/sanctions |
| High | Enhanced (EDD) | AUS-Advanced3V-TwoPlusID | All Standard + biometrics, document authenticity, adverse media |
Quick Implementation Flow
Decision Outcomes
| Outcome | Action |
|---|---|
| PASS | Activate account, send welcome notification |
| REVIEW | Route to compliance queue, inform customer |
| FAIL | Record rejection, send customer-safe message |
- Configure triggers for refresh (e.g., profile changes, new PEP/adverse media hits)
- Use AML screening and fraud signals to inform ongoing risk rating over the customer lifecycle
Risk-Based CDD Tiers
Under Australia’s AML/CTF reforms, customer due diligence follows a three-tiered model aligned with FATF recommendations. FrankieOne workflows map to each tier:| CDD Tier | When to Apply | FrankieOne Workflow | Verification Intensity |
|---|---|---|---|
| Simplified CDD | Low-risk customers, standard products, established relationships | AUS-Basic3V-TwoPlusID | Government ID + credit bureau + electoral roll + screening |
| Standard CDD | Medium-risk customers, most new account openings | AUS-Advanced1V-IDOnly | Government ID verification + screening |
| Enhanced CDD (EDD) | High-risk customers, PEPs, high-value products, complex structures | AUS-Advanced3V-TwoPlusID | Full verification + biometrics + document authenticity + adverse media + manual review |
- Simplified CDD — Appropriate where ML/TF risk is demonstrably low. Reduced verification intensity, but identification still required. Your AML/CTF program defines eligible scenarios.
- Standard CDD — The baseline for most customer onboarding. Meets current AUSTRAC expectations for identity verification.
- Enhanced CDD — Required when risk factors are elevated. Includes additional verification steps, deeper screening, and ongoing enhanced monitoring.
Note: The reforms allow reporting entities flexibility in how they apply these tiers based on their risk assessment. FrankieOne’s configurable workflows support all three tiers and can be adjusted as your AML/CTF program evolves.
Workflow Selection Guide
| Customer Type | Product Risk | CDD Tier | Recommended Workflow |
|---|---|---|---|
| Australian citizen, standard account | Low | Simplified | AUS-Risk-CDD-Email-Phone → Basic3V |
| Australian citizen, new relationship | Medium | Standard | AUS-Risk-CDD-Email-Phone → Advanced1V |
| Australian citizen, high-value product | Medium-High | Enhanced | AUS-Risk-CDD-Email-Phone → Advanced3V |
| Temporary resident | Medium | Standard/Enhanced | AUS-Risk-CDD-Email-Phone → Advanced1V or Advanced3V |
| Foreign national, non-resident | High | Enhanced | AUS-Advanced3V-TwoPlusID + manual review |
| PEP or PEP associate | High | Enhanced | AUS-Advanced3V-TwoPlusID + manual review |
| Business/Trust | High | Enhanced | Business verification (KYB) |
Support
- Documentation: docs.frankieone.com
- Support: Contact your FrankieOne representative
Expanded Details
Regulatory Context
Disclaimer: The information in this section is provided for general guidance only and does not constitute legal or compliance advice. Customers must seek independent AML/CTF compliance advice to ensure their implementation meets their specific regulatory obligations. FrankieOne is not responsible for customers’ compliance decisions or outcomes.
AML/CTF Reforms: The Australian Government is implementing significant reforms to the AML/CTF regime. Customers should review the latest guidance and legislative changes to ensure ongoing compliance:
AUSTRAC AML/CTF Act Obligations
Australian banks must comply with the Anti-Money Laundering and Counter-Terrorism Financing Act 2006 (AML/CTF Act). FrankieOne’s banking workflows can support these core obligations:| Obligation | Requirement | How FrankieOne Can Support |
|---|---|---|
| Customer Identification | Collect and verify customer identity before providing designated services | Automated identity verification against government data sources |
| Ongoing Customer Due Diligence | Monitor customers and transactions on an ongoing basis | Re-verification triggers and screening refresh (where configured) |
| AML/CTF Program | Establish and maintain a compliant program | Configurable risk rules aligned to your program |
| Reporting | Submit SMRs, TTRs, and IFTIs as required | Audit trails and exportable verification and audit data |
Customer Identification Requirements
AUSTRAC’s customer identification procedure for individuals involves collecting and verifying specific information before providing a designated service. FrankieOne’sAUS-Basic3V-TwoPlusID workflow is designed to support these requirements.
Common Collection Requirements:
Common practice is to collect all three of the following. Your AML/CTF program defines specific requirements for your customer type and channel.
| Information | Description | FrankieOne Collection |
|---|---|---|
| Full Name | Customer’s complete legal name | Captured via form input and document OCR |
| Date of Birth | Customer’s DOB | Captured via form input and document OCR |
| Residential Address | Customer’s current residential address (not PO Box) | Captured via form input with address standardisation |
- Full name - verified against a reliable and independent source
- Either date of birth OR residential address - verified against a reliable and independent source
| Requirement | FrankieOne Verification |
|---|---|
| Full Name Verification | Verified against DVS (passport, driver licence, Medicare, visa) and cross-referenced with credit bureau records |
| Date of Birth Verification | Validated via eligible document verification responses (where available) with consistency checks across data sources |
| Residential Address Verification | Verified against electoral roll, credit bureau, and utility records; GNAF standardisation applied |
| Government ID Verification | DVS verification for eligible documents (passport, driver licence, Medicare card, visa); birth certificates and citizenship certificates supported as identity evidence depending on configuration |
Electronic Verification for Risk-Based Onboarding
FrankieOne supports electronic verification procedures that meet current AUSTRAC customer identification expectations (2+2 style) and can be configured to support the upcoming single, risk-based CDD model. Requirements are defined by your AML/CTF program; customers should validate specific requirements with their compliance advisers. This configuration is designed to adapt as Australian AML/CTF reforms consolidate customer identification into a single, risk-based CDD obligation and refine ongoing monitoring expectations.| Requirement | FrankieOne Support |
|---|---|
| Multiple independent sources | Supports verification across multiple electronic data sources, depending on configuration |
| Government source | Supports Australian government document verification via DVS |
| Name + additional attribute | Supports verification of name, DOB, and address |
| Reliable and up-to-date data | Uses real-time electronic data sources where available |
APRA Prudential Standards
For ADIs (Authorised Deposit-taking Institutions), additional APRA requirements apply:- CPS 234 (Information Security): FrankieOne is ISO 27001 certified and data is encrypted at rest and in transit
- CPS 220 (Risk Management): Configurable risk thresholds align verification intensity to your risk appetite
- CPS 231 (Outsourcing): FrankieOne provides security, risk, and operational documentation (e.g., ISO 27001, SOC 2 Type II, data residency, and subcontractor disclosures) to support customer outsourcing assessments
Workflow Configuration Details
Primary Workflow: AUS-Basic3V-TwoPlusID
This workflow provides baseline verification suitable for low-to-medium risk customers.
Data Sources (example configuration):
| Source Type | Purpose |
|---|---|
| Government document verification (DVS) | Government ID verification |
| Credit bureau (primary) | Identity match |
| Credit bureau (secondary) | Fallback identity match |
| Electoral roll | Address verification |
| Sanctions/PEP lists | AML screening |
Note: Specific data sources and providers depend on your configuration and region. Contact your FrankieOne representative for available options.Verification Logic (illustrative):
Step-Up Workflow: AUS-Advanced3V-TwoPlusID
Triggered when primary verification is inconclusive or risk indicators are elevated.
Additional Checks:
| Check | Description | Trigger Condition |
|---|---|---|
| Biometric facial match | Liveness detection and face-to-document matching | Primary verification inconclusive |
| Document authenticity | Tampering and fraud detection | Document quality or consistency issues |
| Adverse media screening | News and media source checks | PEP match or sanctions near-match |
| Enhanced address verification | Additional address data sources | No electoral roll match |
Note: Specific biometric and screening providers depend on your configuration. Contact your FrankieOne representative for available options.
Risk-Based Orchestration: AUS-Risk-CDD-Email-Phone
This risk model implements a risk-based approach to customer due diligence and ongoing monitoring, consistent with AUSTRAC’s expectations and the direction of current AML/CTF reforms in Australia.
This orchestration workflow evaluates risk signals at verification start and automatically routes customers to the appropriate verification path. A single-call approach that eliminates manual step-up decision logic.
Risk Signals Evaluated:
| Signal | Risk Level | Description |
|---|---|---|
| Email age under 30 days | High | Recently created email address |
| Email domain disposable | Critical | Temporary email service detected |
| Phone type = VoIP | Medium | Non-mobile number provided |
| Phone carrier mismatch | Medium | Carrier doesn’t match country |
| IP geolocation mismatch | High | IP country differs from claimed residence |
| Device fingerprint velocity | High | Same device used for multiple applications |
| Session anomalies | Medium | Unusual browser/device patterns |
| Customer risk rating | Variable | Higher ratings drive enhanced due diligence and more frequent reviews |
- Email aged 6 months or more
- Valid mobile phone number matching country
- IP geolocation matches claimed residence
- No device velocity concerns
- Standard product application
- Recently created email (under 30 days)
- Disposable email domain
- VoIP or invalid phone number
- IP/residence mismatch
- Device linked to multiple applications
- High-value product application
- Simplified integration (one API call)
- Automatic risk-based routing
- Consistent risk assessment
- Reduced development overhead
- Real-time fraud signal evaluation
Step-Up Workflow Approaches
FrankieOne offers two approaches for implementing risk-based step-up verification. Choose the approach that best fits your integration requirements and desired level of control.Note: The examples in this section are illustrative and show conceptual patterns. Actual API endpoints, request/response formats, and workflow names may vary. Refer to the FrankieOne API documentation for current implementation details. Workflow availability depends on your plan and configuration.
Option A: Risk-Based Orchestration Workflow (Example: AUS-CDD-Risk)
For streamlined integration, use a risk-based orchestration workflow that automatically adjusts verification intensity based on real-time risk assessment. Availability and configuration of risk-based orchestration workflows depends on your plan and implementation.
How it works:
A risk-based orchestration workflow evaluates risk signals at the start of verification and automatically selects the appropriate verification path:
Risk Factors Evaluated:
| Factor | Low Risk | High Risk |
|---|---|---|
| Product type | Everyday account, basic savings | Home loan, business account, high-limit credit |
| Customer nationality | Australian citizen/PR | Foreign national, high-risk jurisdiction |
| PEP indicators | None | Any PEP level detected |
| Age of customer data | Existing customer, data under 12 months | New customer, no prior relationship |
| Channel | Branch, established digital | New device, VPN detected |
| Transaction profile | Standard patterns | Unusual for demographic |
- You want simplified integration with a single API call
- You prefer FrankieOne to manage risk-based orchestration
- Your risk appetite aligns with standard banking risk tiers
- You want consistent risk assessment across all customers
Option B: Explicit Multi-Workflow Chaining
For maximum control, you can explicitly call two or more workflows in sequence, implementing your own step-up logic based on the results of each workflow. How it works: When to use this approach:- You need custom step-up logic based on your specific risk appetite
- You want to integrate additional business rules between workflow calls
- You need to call different step-up workflows based on the failure reason
- You require detailed control over the customer experience at each stage
Comparison: CDD Risk vs Explicit Multi-Workflow
| Aspect | CDD Risk Workflow | Explicit Multi-Workflow |
|---|---|---|
| API calls | 1 (single call) | 2+ (one per workflow) |
| Step-up logic | FrankieOne managed | Your implementation |
| Customisation | Configurable thresholds | Full control |
| Integration complexity | Lower | Higher |
| Risk assessment | Built-in risk engine | Your rules |
| Best for | Standard banking flows | Complex custom logic |
Step-by-Step Implementation
Note: This section describes the conceptual implementation flow. For actual API endpoints, request/response schemas, and code examples, refer to the FrankieOne API Documentation.
Prerequisites
Before implementing, ensure you have:- FrankieOne API credentials
- Webhook endpoint configured and accessible
- OneSDK embedded in your application (recommended) OR direct API integration
- Test environment access for sandbox verification
Step 1: Create Individual
Create a customer record with collected personal information:- Full name (given, middle, family)
- Date of birth
- Residential address
- Contact details (phone, email)
- Your internal customer reference
Step 2: Upload Identity Documents
Submit government-issued ID for verification. Supported Document Types:| Document Type | Description |
|---|---|
| Australian Passport | International travel document |
| Driver Licence | State-issued driver licence |
| Medicare Card | Healthcare entitlement card |
| Visa | Immigration document |
| Birth Certificate | Birth registration document |
| Citizenship Certificate | Citizenship evidence |
Step 3: Execute Verification Workflow
Trigger the KYC workflow for the individual. The workflow will:- Verify identity against government and commercial data sources
- Perform PEP and sanctions screening
- Assess fraud risk signals
- Return an outcome (PASS, REVIEW, or FAIL)
Step 4: Handle Webhook Events
Configure your webhook endpoint to receive verification results asynchronously. Typical Webhook Events:| Event Type | Description | Recommended Action |
|---|---|---|
| Workflow completed | Verification finished | Process outcome (PASS/REVIEW/FAIL) |
| Workflow failed | System error occurred | Retry or escalate to support |
| Review required | Manual review needed | Route to compliance queue |
| Screening alert | New screening match found | Investigate alert |
| Document rejected | Document validation failed | Request new document from customer |
Step 5: Process Decision Outcomes
Handle verification outcomes in your application: PASS Outcome:- Update customer KYC status to verified
- Activate account and enable features
- Send welcome notification
- Create internal review case with priority and SLA
- Notify compliance team
- Update customer status to pending review
- Inform customer their application is being reviewed
- Record rejection with internal reason codes
- Update application status
- Send customer-safe rejection notification (without sensitive details)
- Log for audit purposes
Risk Tier Examples
Tier 1: Low Risk - Auto-Approve
Customer Profile:- Australian citizen
- Valid Australian passport or driver licence
- Residential address matches electoral roll
- No PEP or sanctions matches
- Email and phone pass fraud checks
Mary Testone, 32, applies for an everyday transaction account via mobile app. She provides her Victorian driver licence and current address. Government ID verification confirms the licence is valid, credit bureau matches her name and DOB, electoral roll confirms her address. No screening matches. Account activated.
Tier 2: Medium Risk - Enhanced Due Diligence
Customer Profile:- Foreign national with Australian visa
- PEP Level 2 or 3 (family member or close associate)
- Minor discrepancies in data matching
- Higher-value product (e.g., home loan, business account)
James Testtwo, 45, applies for a business transaction account. He’s a permanent resident originally from Singapore. His father is a former Singaporean government minister (PEP Level 2). Government ID validates his passport, but no electoral roll match (recent address change). System triggers step-up: biometric check passes, no adverse media found, address verified via alternative source. Case routed to compliance for PEP assessment. Compliance approves with enhanced monitoring flag.
Tier 3: High Risk - Manual Review Required
Customer Profile:- Sanctions list near-match (similar name, different DOB)
- Adverse media findings
- Multiple identity documents with discrepancies
- High-risk jurisdiction connections
- Fraud signals detected
Robert Testthree, 38, applies for a savings account. Name returns a near-match on sanctions list (different middle name and DOB). Adverse media search finds articles about a fraud investigation involving someone with a similar name. Biometric passes. Case escalated to senior compliance officer. After investigation: sanctions match confirmed as false positive (different person), adverse media relates to different individual. Approved with standard monitoring.
Tier 4: Auto-Reject
Triggers for Automatic Rejection:| Trigger | Rationale | Customer Communication |
|---|---|---|
| Confirmed sanctions match | Legal prohibition | ”Unable to proceed with application” |
| Document confirmed fraudulent | Fraud prevention | ”Unable to verify identity” |
| Age verification failed (under 18) | Product eligibility | ”Age requirement not met” |
| Duplicate application (fraud pattern) | Fraud prevention | ”Application already exists” |
| Deceased indicator | Data integrity | ”Unable to verify identity” |
| Device/IP on fraud blocklist | Fraud prevention | ”Unable to proceed at this time” |
Edge Cases and Special Handling
Name Mismatches
| Scenario | Example | Handling |
|---|---|---|
| Married name change | Licence: Sarah Testfive, Passport: Sarah Testsix | Accept with statutory declaration or marriage certificate |
| Transliteration variance | Mikel vs Mikael vs Michael | Fuzzy matching; manual review if below threshold |
| Hyphenated names | Emma-Test vs Emma Test vs EmmaTest | Normalise hyphens and spaces before matching |
| Name order differences | Wei Testseven vs Testseven Wei | Support both Western and Eastern name order conventions |
| Titles and suffixes | Dr. Tom Testeight Jr. vs Tom Testeight | Strip titles/suffixes before matching |
| Accent marks | José Testnine vs Jose Testnine | Normalise diacritics for matching |
Document Expiry Handling
| Document Type | Expired Acceptance | Grace Period | Conditions |
|---|---|---|---|
| Passport | No | 0 days | Must be current |
| Driver Licence | Conditional | 90 days | If renewal in progress |
| Medicare | Yes | 2 years | For identity only, not entitlement |
| Visa | No | 0 days | Must be current and valid |
| Birth Certificate | Yes | N/A | No expiry |
| Citizenship Certificate | Yes | N/A | No expiry |
Re-verification Triggers
| Trigger | Re-verification Level | Timeframe |
|---|---|---|
| Product upgrade (e.g., basic → premium) | Document refresh | Before activation |
| Dormant account reactivation (over 12 months) | Full re-verification | Before reactivation |
| Significant transaction pattern change | Risk reassessment | Within 7 days |
| Customer-initiated detail change | Verify changed elements | Immediate |
| Screening alert on existing customer | Enhanced due diligence | Within 24 hours |
| Regulatory requirement (periodic review) | Full re-verification | Per risk rating schedule |
| Fraud indicator detected | Full re-verification + fraud checks | Immediate |
Periodic Review Schedule
| Customer Risk Rating | Review Frequency | Scope |
|---|---|---|
| Low | Every 3 years | Screening refresh, address confirmation |
| Medium | Annually | Full identity re-verification |
| High | Every 6 months | Full re-verification + enhanced screening |
| PEP | Every 6 months | Full re-verification + adverse media |
Joint Account Handling
All account holders must be independently verified before account activation.Minor Accounts (Under 18)
| Account Type | Age Range | Requirements |
|---|---|---|
| Youth saver | 14-17 | Minor KYC + parent/guardian verification |
| Child trust | 0-17 | Parent/guardian KYC only; minor recorded |
| Teen everyday | 16-17 | Minor KYC + parent/guardian consent |
Non-Resident Accounts
| Customer Type | ID Requirements | Additional Checks |
|---|---|---|
| Tourist/Visitor | Foreign passport + visa | Visa validity, travel history |
| Temporary resident | Passport + valid visa | VEVO check, visa conditions |
| Foreign student | Passport + student visa | CoE verification |
| Working holiday | Passport + WHV | VEVO check |
Compliance Reporting
Audit Trail Requirements
FrankieOne maintains comprehensive audit trails for all verification activities.| Data Category | Retention Period | Purpose |
|---|---|---|
| Verification requests | 7 years | AML/CTF compliance |
| Document images | 7 years | Evidence retention |
| Decision outcomes | 7 years | Audit trail |
| Screening results | 7 years | AML/CTF compliance |
| API request/response logs | 2 years | Technical audit |
| Webhook delivery logs | 90 days | Troubleshooting |
AUSTRAC Reporting Support
FrankieOne provides data exports to support AUSTRAC reporting requirements:- Subject details and identification documents
- Verification history
- Screening alerts and suspicious indicators
Note: Transaction monitoring and patterns are typically managed by your core banking system, not FrankieOne.
Regulatory Examination Support
FrankieOne can assist with generating examination packages for AUSTRAC or APRA examinations.| Section | Description |
|---|---|
| Executive Summary | Verification volumes, pass rates, key metrics |
| Policy Documentation | Current workflow configurations and thresholds |
| Screening Summary | PEP/sanctions alerts and resolution outcomes |
| Manual Review Log | All manual decisions with rationale |
| Exception Report | Cases outside normal parameters |
| System Change Log | Configuration changes with approvals |
| Sample Cases | Representative examples from each outcome category |
Troubleshooting
| Issue | Likely Cause | Resolution |
|---|---|---|
| Government ID verification returning “NO_MATCH” | Name/DOB format mismatch | Check date format (YYYY-MM-DD), remove titles from name |
| Biometric check failing repeatedly | Poor image quality | Guide user on lighting, positioning; allow retry |
| Webhook not received | Firewall blocking | Whitelist FrankieOne IPs; check endpoint accessibility |
| High false positive rate on screening | Thresholds too sensitive | Tune matching thresholds; implement exclusion lists |
| Slow response times | Configuration issue | Contact FrankieOne support for optimisation |