Security and governance

Security and AI governance at a glance.

Where each step runs, what the Simple Fund 360 connection reads and writes, and how your fund's data is held. Written for a practice principal; a BGL reviewer and a program assessor read the same page.

1Fund records and BGL data are stored and processed in Sydney.
2Data read from BGL is never sent to the AI model.
3Only the text of documents the trustee forwards or uploads, and the request it answers, go to Anthropic in the United States. Deleted within 30 days, not used for training.
4Two-step sign-in is required for every BGL-connected user, and the trustee confirms before anything is written back.
5Every BGL security event is recorded in an append-only ledger kept at least 12 months.

AI never calculates tax, determines a compliance outcome or posts an unconfirmed record.

How data moves

Seven steps, and where each one runs.

The same seven steps as How it works, with the location of each. Rules and the ledger are code running in Sydney. The AI step is the only step at which anything leaves Australia, and only document text goes.

1
Expected evidence
Rules
The fund's holdings in Simple Fund 360 set the list of evidence the year needs.
Where it runs
Application functions in Sydney read the fund under the audit scope over TLS. The result is stored with Supabase in Sydney.
2
Already held
Rules
Documents, tags and workpapers already in Simple Fund 360 come off the list. Only the gap is carried forward.
Where it runs
Sydney functions and the Sydney database. Nothing leaves Australia at this step.
3
Collect what is missing
Rules
One open request per fund, in one plain email to the trustee. One scheduled check per fund per Sydney day.
Where it runs
The email is sent through Resend in the United States and carries the fund's display name and the request title, not BGL account data.
4
AI reads the document
AI
The document the trustee forwards or uploads is read and classified: document type, what it relates to, financial year and period covered. An uncertain read is not matched.
Where it runs
The file is stored in a private bucket in Sydney. Its extracted text and the request it answers go to Anthropic in the United States. The file itself and anything read from BGL do not.
5
Trustee confirms
Trustee
A match shows the trustee a Confirm button next to the request it answers. Nothing is filed before the trustee presses it.
Where it runs
In the product, behind two-step sign-in, on Sydney functions. The confirmation and who made it are recorded.
6
Written back to Simple Fund 360
Rules
On Confirm the document is written to the fund's Documents in Simple Fund 360, tagged with the year, the type and SMSF Core. That is the only write.
Where it runs
Sydney functions to api.bgl360.com.au over TLS. Nothing in the fund is changed or deleted.
7
Logged
Ledger
Every step, from the request opening to the write-back, is recorded with what happened, who did it and when.
Where it runs
Append-only tables in the Sydney database. Rows are never updated or deleted by the application.

AI boundary

What the AI does, and the two controls a trustee holds.

AI reads documents and can draft suggested entries. Deterministic rules handle evidence requirements and tax calculations. Nothing is recorded until the trustee confirms.

Where the boundary sits

The model reads and classifies. It does not choose what a fund needs, does not mark a request done, and has no file step. The practice has no approve step either: the trustee is the only approval, and it comes before the only write.

AI document reading, per fund

A trustee can turn AI document reading off for a fund. When it is off, the model is not called for that fund's uploads or forwarded email, and the practice workspace shows that reading is off.

First-connection acknowledgement

When a fund is first connected to Simple Fund 360 the trustee is shown who receives document text, where it is processed, what is and is not sent, and how long it is kept, and their acknowledgement is recorded against the fund.

For registered tax practitioners, this design is intended to support practices in maintaining review, human control, traceability and transparent AI use. The practitioner's own obligations stay with the practitioner.

BGL connection and permissions

One scope, one write, revocable by the trustee.

Audit scope

The connection runs under BGL's audit scope. SMSF Core reads the fund list, trial balance, documents, tags, transactions, workpapers, investment summary, members, trustees and lodgements. The one write is a document upload with tags to the fund's Documents. Nothing in the fund is changed or deleted.

Trustee consent

The trustee connects through BGL's own consent flow. The OAuth state is bound to the signed-in user with an HMAC, expires after 10 minutes, is compared in constant time, and the callback is rate-limited per user. No code, token or error detail is ever placed in a URL, log line or page.

Revocation

A trustee can remove the connection in the product; its stored tokens are deleted and the removal is recorded in the ledger. Practice access to a fund exists only through a trustee-granted link and can be revoked by the trustee with immediate effect.

Tokens

Access and refresh tokens are encrypted in the application with AES-256-GCM before they are written to the database; the table holds ciphertext only, with a fresh random IV per encryption and the authentication tag stored alongside, so tampering is detected on decrypt.

Key

The 256-bit key is held only as an environment variable in the hosting platform's encrypted store, never in the repository, a configuration file or the database. One backup copy sits in an MFA-protected vault controlled by the Director. Rotation is manual and the ciphertext carries a version prefix for it.

Who can read a token

Under row-level security the row is readable by the fund owner. The scheduled worker reads it server-side for the daily check. Practice users cannot read it. There is no external API and no bulk export of BGL-sourced data to anyone.

Identity and access

Two-step sign-in for every BGL-connected user; one person in production.

Sign-in

Sign-in is a single-use magic link with PKCE through the database provider's hosted auth service; there is no custom authentication. Sessions are validated server-side on every request, never from a cookie alone.

Two-step sign-in

TOTP enrolment is enforced at the first request for any BGL-connected surface. A user with a connected fund cannot reach fund data, documents, reconciliation or the practice workspace until an authenticator is enrolled and verified. Practice members are gated the same way.

Access in the database

Row-level security on every table; direct update and delete revoked on the ledgers; function-level access enforced three times, at the page, the server action and in Postgres. Per-user rate limits cover checkout, two-step sign-in, the BGL callback and other sensitive routes.

Production access

The Director is the only person with production access, on hosting, database, source control, payments, email delivery, error monitoring, workspace email and the BGL developer portal, all behind MFA. There are no employees or contractors. Access is reviewed quarterly.

The one machine credential

The CI pipeline holds a database service-role key as a repository secret. It is used only by the calculation parity and citation checks, which call calculation functions with synthetic inputs and read the citation reference table; no fund or BGL data is read. It is rotatable from the database console and is scheduled to move to a non-production database project.

Session cookies

Secure and SameSite=Lax, issued over HTTPS only. They are not HttpOnly, because the browser-side auth client takes part in the PKCE exchange. The compensating controls are server-side session validation on every protected route, an enforced Content-Security-Policy and TOTP for BGL-connected access.

Encryption and key management

TLS in transit, AES-256 at rest, a second layer on credentials.

In transit

All data-bearing traffic is HTTPS; HTTP is redirected at the edge. TLS 1.3 is negotiated by default, TLS 1.2 is available and TLS 1.0 and 1.1 are refused. HSTS is set for two years. Functions talk to BGL only at api.bgl360.com.au.

At rest

Supabase encrypts all customer data, including database storage and backups, with AES-256. Uploaded documents sit in a private bucket reachable only through 60-second signed links. No BGL data is stored on staff devices.

Credentials

BGL and broker tokens are encrypted a second time inside the application with AES-256-GCM before storage, keyed from an environment variable that never enters the database or the repository, so the tokens are unreadable even to someone holding a database dump.

Headers

Every route carries an enforced Content-Security-Policy with frame-ancestors none, X-Content-Type-Options nosniff, X-Frame-Options DENY, a strict Referrer-Policy and a Permissions-Policy. CSP violations are reported to us.

Audit logging

An append-only ledger for every BGL event.

Access to BGL-connected data is recorded in an append-only security audit ledger: actor id, opaque fund id, event, success or failure, source and timestamp. Update and delete are revoked from the application roles, and for this ledger from the service role too; a migration-replay test fails if a revoked grant is reopened.

There is no purge job, so retention is at least 12 months. The rows carry no foreign key to the fund and survive fund deletion. Evidence requests and calculation runs carry their own append-only event logs.

Logs never contain tokens, codes or fund identifiers beyond opaque ids. Before an error event leaves the application a scrubber redacts emails, ABN and TFN patterns, dollar amounts and labelled names.

Two limits, stated plainly: platform request logs are shorter (hosting runtime logs one day, database API logs seven days) and are not drained to long-term storage during the pilot; and the database owner role, reachable only through the MFA-protected console, is not technically prevented from altering rows. There is no separate tamper-evident log store.

Events in the ledger

oauth_connected
oauth_failed
token_refresh
bgl_read
bgl_document_download
bgl_document_write
practice_access
access_denied
mfa_required
mfa_completed
connection_removed

Every row has a timezone-aware timestamp, the acting user's id, the acting subsystem and a typed event name with a bounded detail field.

Hosting and subprocessors

Fund data in Sydney; four providers in the United States receive limited adjacent data.

Data read from the BGL API never reaches a United States provider. A written vendor and subprocessor register, reviewed annually, lists every provider with the data it holds, its region, purpose, risk rating and mitigation; it is available on request.

Provider	Where	What it receives	Purpose
Supabase	Sydney, Australia	Fund records, documents, BGL tokens (encrypted twice), audit ledgers	Database, authentication and private document storage
Vercel	Sydney, Australia (functions pinned)	Requests in flight; no data at rest	Application hosting, TLS termination, DDoS mitigation and firewall
Upstash	Sydney, Australia	Request metadata only	Rate limiting
Anthropic	United States	Extracted text of a document the trustee forwards or uploads, and the request it answers. Deleted within 30 days, not used for training.	Reads and classifies documents before the trustee confirms
Resend	United States	Fund display name and request titles; not BGL account data	Sign-in links and evidence request emails
Sentry	United States	Error events with request bodies removed and identifiers scrubbed	Error monitoring
Stripe	Contracted through Stripe Australia; processed in the United States	Payment details; card numbers never reach us	Payments and subscriptions
Plausible	European Union	Cookie-free, aggregate page counts; no BGL data	Analytics

Vulnerability management and independent assurance

What is tested today, and what is not yet.

Dependency alerts

Dependencies are lockfile-exact and monitored by automated alerts. Fixes are due within 48 hours for critical, 7 days for high, 30 days for moderate and monthly for low severity. The backlog is reviewed weekly.

CI security gate

Every pull request fails on a new table without row-level security, on privileged-client use outside a reviewed allow-list, on banned patterns, and on a typecheck or build failure. Error monitoring, CSP violation reports and an hourly automated health check run in production.

Application controls

CSRF, cross-site scripting, SQL injection and redirect handling follow OWASP guidance: SameSite cookies and Origin checks, React escaping with an enforced CSP, parameterised database access with no string-built SQL, and same-origin-only redirect targets pinned by tests.

Independent penetration test

Not yet. Testing to date has been internal: a code-level review of the AI surfaces and a five-repository security audit, both in July 2026, plus the per-pull-request gate. An independent penetration test is scheduled for the first quarter of 2027, before the pilot cohort grows beyond the first practices. The date and a summary will be published here.

Certifications

We hold neither ISO 27001 nor SOC 2, and controls have not been independently verified. They are drawn from OWASP guidance, the framework and database provider security guides and the Australian Privacy Principles, and are enforced in code and CI rather than by a certified management system.

Infrastructure

We operate no servers, containers or network devices. Platform hardening, patching and DDoS mitigation are the hosting and database providers'. We have not commissioned an external infrastructure scan, and the configuration has not been checked against NIST SP 800-123.

Backups, incident response and deletion

Daily backups, a written runbook, deletion on request.

Backups

Daily platform backups with seven-day retention, so the recovery point is at most 24 hours. Point-in-time recovery is not enabled. A restore drill has not yet been run; one is scheduled to be completed by 15 October 2026.

Incident response

A written runbook covers detection, severity, first-hour containment (scheduler kill switch, disabling the affected BGL connection and deleting its tokens, secret rotation, provider-side revocation coordinated with BGL), customer and BGL notification, an OAIC notifiable data breach assessment under the Privacy Act, evidence preservation and a post-incident review within seven days.

Breach notification

Any confirmed or suspected breach exposing BGL client data or API tokens is reported to BGL immediately, in addition to our obligations under the Notifiable Data Breaches scheme. No security incident or data breach has occurred; one availability incident in September 2026 was resolved the same day with no data exposure.

Deletion

A trustee lodges a deletion request in the product. It is completed within 30 days after SIS Act retention windows are checked, and the deleted records then age out of the seven-day backup window. Security events, which carry only opaque ids, are retained.

Exports

Records are portable by design. BGL SF360, Class and CSV exports are free on any plan, during the trial and after a subscription ends; a lapsed account drops to read-only rather than disappearing.

Privacy Act

The Privacy Act small-business exemption was removed effective 1 July 2026. We treat trustee data as personal information under the Australian Privacy Principles. The privacy policy names every processor and its location.

Due-diligence material

The ten questions a reviewer asks, answered on one page.

For a practice's vendor review or a program assessment, the short version is at Security due diligence: hosting, what reaches the AI provider, MFA, certifications, penetration testing, log retention, production access, token storage, incidents and how to leave with your data.

Available on request at hello@smsfcore.com: the Access Control Policy, the Patch and Dependency Policy, the Incident Response Runbook, the vendor and subprocessor register and the July 2026 internal review records.

Read the due-diligence answers

General information only. Not a licensed financial service.

Start free: 30 days, no card