Building Secure Banking Apps in Australia

Banking apps are different. The data is sensitive, the regulations are strict, and the consequences of getting security wrong are severe. We've built apps for Australian financial institutions, and the process is fundamentally different from building a typical consumer app.

Here's what goes into building a banking app that meets Australian requirements.

The Regulatory Landscape

Australian banking apps must satisfy multiple regulatory frameworks:

APRA CPS 234 (Information Security): Requires ADIs to maintain information security capability commensurate with threats. This means:

• Formal security governance
• Access controls
• Incident management
• Regular testing

Privacy Act 1988 (and APPs): Data protection requirements, including:

• Collection limitations
• Use and disclosure restrictions
• Data quality and security
• Access and correction rights

AML/CTF Act: Anti-money laundering and counter-terrorism financing requirements:

• Customer identification
• Transaction monitoring
• Suspicious matter reporting

Consumer Data Right (CDR): For Open Banking data sharing:

• Consent management
• Data access controls
• API security standards

Plus PCI DSS if handling card data, and various state requirements.

This isn't optional. Get it wrong and you're dealing with APRA enforcement action.

Security Architecture

Defence in Depth

Banking apps need multiple security layers:

[Device] → [App Security] → [Network] → [API Gateway] → [Backend] → [Data]
   ↓           ↓              ↓            ↓              ↓          ↓
Root/JB    Encryption      TLS 1.3     Auth/Rate     Access      Encryption
Detection  Obfuscation     Pinning     Limiting      Control     at Rest
           Secure Storage

Each layer assumes the previous might fail.

Device Security

Before any business logic, validate the device:

Root/Jailbreak Detection: Compromised devices can't be trusted. Detect and limit functionality or block entirely.

Integrity Checking: Verify the app hasn't been tampered with. Check signatures, detect debugging, identify emulators.

Secure Enclave Usage: Use hardware-backed security for cryptographic operations when available.

App Security

Code Obfuscation: Make reverse engineering harder. Not impossible, but harder.

Secure Storage: Credentials, tokens, and sensitive data must be encrypted. Use platform secure storage (Keychain, Keystore).

Certificate Pinning: Don't trust the device's certificate store. Pin your certificates to prevent MITM attacks.

Memory Protection: Clear sensitive data from memory when not needed. Don't leave credentials lying around.

Network Security

TLS 1.3 Only: Older TLS versions have known vulnerabilities.

Certificate Pinning: (Yes, again—it's that important.)

No Data in URLs: Sensitive data should never appear in URLs (they get logged).

Request Signing: Sign API requests to prevent tampering.

API Security

Strong Authentication: OAuth 2.0 / OIDC with proper implementation.

Token Management: Short-lived access tokens, secure refresh token handling.

Rate Limiting: Prevent brute force and abuse.

Input Validation: Trust nothing from the client.

Authentication Patterns

Biometric Authentication

Customers expect Face ID and fingerprint. Implement properly:

// iOS example - proper biometric implementation
let context = LAContext()
context.localizedFallbackTitle = "" // No fallback to passcode

context.evaluatePolicy(
    .deviceOwnerAuthenticationWithBiometrics,
    localizedReason: "Authenticate to access your accounts"
) { success, error in
    if success {
        // Biometric succeeded - now use stored credential
        retrieveCredentialFromKeychain()
    }
}

Biometrics are convenience, not primary security. They unlock access to securely stored credentials.

Step-Up Authentication

Not all actions are equal. Checking balances ≠ transferring $50,000.

Implement risk-based step-up:

• Low risk (balance check): Session authentication
• Medium risk (internal transfer): Biometric confirmation
• High risk (external transfer, payee addition): MFA, possible additional verification

Session Management

• Short session timeouts (5-15 minutes active, 30-60 minutes idle)
• Automatic logout on background
• Single active session (or explicit multi-device management)
• Secure session token storage

Data Protection

Data Classification

Classify all data:

• Public: Marketing content, branch locations
• Internal: Non-sensitive operational data
• Confidential: Customer names, basic account info
• Restricted: Full account numbers, transaction history, credentials

Different classifications = different handling requirements.

Encryption

At Rest: All confidential and restricted data encrypted using AES-256.

In Transit: TLS 1.3 for all communications.

In Processing: Minimise time sensitive data spends decrypted in memory.

Data Minimisation

Don't collect or store what you don't need. If you don't have it, you can't leak it.

On-device, store the minimum needed for functionality. Cache thoughtfully.

Testing and Assurance

Security Testing

SAST (Static Application Security Testing): Automated code scanning for vulnerabilities.

DAST (Dynamic Application Security Testing): Runtime testing for exploitable vulnerabilities.

Penetration Testing: Manual testing by security professionals. Required annually at minimum, often more frequently for banking.

Threat Modelling: Systematic identification of potential threats and mitigations.

Compliance Testing

• APRA CPS 234 compliance assessment
• Privacy impact assessment
• Penetration test against OWASP Mobile Top 10
• CDR compliance testing (if applicable)

Ongoing Monitoring

Security isn't a one-time activity:

• Continuous vulnerability scanning
• Dependency monitoring for known vulnerabilities
• Security incident monitoring
• Regular access reviews

Development Practices

Secure Development Lifecycle

1. Requirements: Security requirements defined upfront
2. Design: Threat modelling, security architecture review
3. Development: Secure coding standards, security training
4. Testing: Security testing at multiple stages
5. Deployment: Secure deployment pipeline, configuration management
6. Operations: Monitoring, incident response, regular review

Code Review

All code reviewed with security lens:

• Authentication and authorisation logic
• Cryptographic implementations
• Input handling
• Error handling (no sensitive data in errors)
• Logging (no sensitive data logged)

Dependency Management

Banking apps can't have vulnerable dependencies:

• Automated scanning for known vulnerabilities
• Prompt patching of security issues
• Minimal dependency footprint
• Vendor security assessment for critical dependencies

User Experience Trade-offs

Security and UX are in tension. Some principles:

Friction at the right moments: Easy for checking balances. More steps for high-risk actions.

Clear communication: Explain why security steps are needed. Users accept friction when they understand the reason.

Remember good devices: Trusted devices can have lighter-touch verification.

Recovery paths: Users forget passwords, lose devices. Secure recovery is essential.

Don't blame the user: Security failures should be handled gracefully, not with accusatory messaging.

The Build vs. Buy Decision

Core banking apps are usually custom-built. But there are components to consider buying:

Buy:

• Identity verification services (Onfido, OCR Labs)
• Fraud detection services
• Push notification infrastructure
• Analytics (with privacy compliance)

Build:

• Core app experience
• Integration with your banking systems
• Security architecture specific to your requirements

Working with Us

We've built mobile banking applications including Newcastle Permanent's mobile app and fintech platforms like Plenti.

Our approach:

• Security-first architecture
• APRA compliance from day one
• Modern UX within security constraints
• Thorough testing and documentation

Banking apps require partners who understand both the technical and regulatory landscape.

Talk to us about your banking app project.