Software That Meets the Demands of Financial Services

CPS 234 requires ADIs and other APRA-regulated entities to maintain information security capabilities commensurate with the size and extent of their threats. In practice, that means we design systems with a formal information asset register, clearly mapped control ownership, third-party assurance requirements (including us as a service provider), and tested incident response runbooks. We produce the artefacts APRA examiners actually ask for — information security policies, penetration test reports, vulnerability management evidence and control effectiveness attestations — rather than just checking a compliance checkbox.

Yes. We have engineers with hands-on integration experience across Temenos T24/Transact, Silverlake BANKS, TCS BaNCS, and several Australian-built platforms including Sandstone and ultracs. Our preferred approach is API-first integration through the vendor's published integration layer, but we've also built robust ETL and messaging bridges where the core system predates modern APIs. We work closely with your vendor's professional services team to align on the integration architecture before writing a line of code.

Australian AML/CTF obligations under the Anti-Money Laundering and Counter-Terrorism Financing Act 2006 require reporting entities to implement a risk-based compliance programme including customer identification procedures, ongoing due diligence, transaction monitoring and suspicious matter reporting to AUSTRAC. We build automated KYC onboarding workflows that connect to identity verification providers (such as Illion, Equifax or Green ID), sanctions screening APIs and PEP databases, with configurable risk-scoring rules and a case management interface for your compliance team to investigate and file SMRs.

We default to Australian-region deployments (AWS Sydney/Melbourne, Azure Australia East/Southeast or GCP Sydney) for all production data unless there is a compelling reason to do otherwise. For APRA-regulated entities, we document the data residency position in the system architecture record and ensure any cross-border data flows are captured in the group's data governance register as required by CPS 234 and privacy obligations under the Privacy Act. We do not use US-only services for storage of account holder data without explicit approval and appropriate data processing agreements.

Absolutely — and the needs are quite different. With early-stage fintechs we tend to focus on building a compliant, scalable foundation quickly: robust identity verification, a clean API contract, event-sourced data models that don't paint you into a corner, and an architecture that can absorb a Series A growth event without a rewrite. With established ADIs and insurers the focus is usually modernisation, compliance uplift or building net-new digital products alongside existing infrastructure. We've advised companies on their AFSL and ACL obligations, and we know when to refer you to specialist legal counsel.