Protecting client data
Security, hosting and how the platform is built
Client financial data is among the most sensitive a practice holds. Use this overview to start a discussion about access, hosting and data handling for your practice.
The controls
What protects the data, and where
Review access controls and discuss your practice's hosting and data-handling requirements during setup.
Getting in
Authentication is handled by a dedicated service, separate from the portals and from the services holding client data.
Key-protected API
Every HTTP endpoint is private and requires a stage-specific API key.
JWT authorisation
A Lambda authoriser validates the token on requests before any handler runs.
Hashed credentials
Passwords are hashed with bcrypt, never stored in readable form.
Revocable sessions
Tokens are revoked on logout so a signed-out session cannot be replayed.
Who can see what
Access follows the roles an advice practice actually has, rather than a single shared login.
Role-based access
Privileges separate account owner, adviser, paraplanner, research manager and admin.
Verified email and reset
Email verification and expiring password reset tokens for advisers and clients.
Where it runs
Discuss production hosting, environment separation and data handling with the team as part of your practice assessment.
Australian region hosting
Services run in AWS ap-southeast-2, the Sydney region.
Isolated environments
Separate development, QA, UAT and production stages with their own configuration.
Architecture
Twelve services, one boundary at the edge
Souffle runs as twelve independently deployable backend services on AWS Lambda and API Gateway in the ap-southeast-2 Sydney region. Every HTTP endpoint is private and requires a stage-specific API key, and a Lambda authoriser validates the JSON Web Token before any handler runs.
Uploaded files and images are held in dedicated S3 buckets per service and per stage, and local, development, QA, UAT and production each carry their own configuration — so a change can be proven before it reaches a practice.
How the platform is built
Where your data runs, and what that buys a practice
Souffle is not one application with a database behind it. It is twelve independently deployable services and four front ends, which is why capability can be added without disturbing what a practice already relies on.
12
Backend services
Independently deployable
4
Front ends
Adviser, client, admin, onboarding
5
Environments
Local, dev, QA, UAT, production
AU
Region
AWS ap-southeast-2, Sydney
Twelve services, not one monolith
Authentication, client data, SMSFs, trusts, companies, partnerships, payments, settings, shared utilities, the kanban board, the adviser portal and the administration portal each run as their own service. A change to one is deployed on its own, and a service under load scales independently of the rest.
Serverless, in the Sydney region
Services run on AWS Lambda behind API Gateway in ap-southeast-2. There is no server to keep patched, capacity follows demand, and client data is processed in the same region the practice operates in.
A closed edge
Every HTTP endpoint is private and requires a stage-specific API key, and a Lambda authoriser validates the JSON Web Token before any handler runs. Passwords are hashed with bcrypt, tokens are revoked on logout, and email verification and password reset tokens expire.
Four front ends, one data model
The adviser portal, the client portal, the administration portal and the lead onboarding form are separate applications reading the same records — which is why a lead that completes the onboarding form becomes a client without anything being re-keyed.
Storage and documents
Uploaded files and images are held in dedicated S3 buckets, separated per service and per stage. Documents, questionnaires, templates and client records are stored in MongoDB through Mongoose schemas.
Market and reference data
ASX company data, ASX real-time indices and an S&P view are available in the platform, alongside cryptocurrency prices and exchange rates — so a valuation conversation does not need a second browser tab.
Email is sent through AWS SES, with a mailbox in the platform, stored email templates, bulk email to client groups, and per-member email signatures. Team members can configure preferences for task notifications during practice setup.
Environments and documentation
Local, development, QA, UAT and production each carry their own configuration and their own storage, so a change is proven before it reaches a practice. Each service generates its own OpenAPI documentation, and structured logging runs through pino.
Get started
See Souffle with your own practice in mind
Walk through client records, lead onboarding, workflow boards, modelling and the client portal with someone who knows Australian advice practices.