Privacy & data residency

If you're handling Malaysian SME financials, you need to know exactly where the data goes and who can see it. This page lays it out — physical region, legal jurisdiction, encryption, isolation, retention.

For the audience that asks: I'm an IT person or a compliance officer evaluating Kiravy. Skim the headings; we keep claims concrete.

Where data physically lives

Layer	Provider	Region
Database (Postgres)	Supabase	ap-southeast-1 (Singapore)
File storage (receipts, logos, exports)	Supabase Storage	ap-southeast-1 (Singapore)
App servers	Self-hosted on a VPS	Currently Frankfurt (eu-central); production move to ap-southeast-1 is planned
AI processing	The AI provider Kiravy uses	US region for inference; data not retained by the provider beyond the immediate request
Email (invitations, password resets)	Supabase Auth → SMTP relay	Singapore
Error monitoring	Sentry	EU region; PII-scrubbed before send
Analytics	PostHog	Self-hosted; no third-party trackers

The principle: everything customer-data-related sits in Singapore. The VPS region for the app server is a temporary state during the staging phase; production will collocate with the data layer.

What encryption looks like

• In transit: Every connection is TLS 1.2+ — the browser ↔ Kiravy, the Kiravy app ↔ Supabase, the SQL Account bridge ↔ Kiravy. No plaintext anywhere on the wire.
• At rest: Supabase encrypts the database and storage buckets with AES-256.
• Bearer tokens (used by the SQL Account bridge agent): only the SHA-256 hash is stored server-side. The raw token exists for a few seconds at pair time, then disappears. Even Kiravy support can't see it after creation — if you lose the token, you re-pair.

Tenant isolation — the database does it

Every read and write goes through PostgreSQL Row-Level Security (RLS) policies before the application sees the data. This is enforced by the database, not the app — a buggy query or a forgotten WHERE clause cannot leak data across firms.

Two helper functions back this up:

• current_user_workspace_role() — returns the calling user's role in the active workspace
• is_assigned_to_client(client_id) — returns true if the user is Partner / Manager or explicitly assigned to that client

Every tenant table has a policy like:

create policy "tenant_isolation" on transactions for select
  using (is_assigned_to_client(client_id));

This is the same mechanism that makes Kiravy AI safe — the AI's tool calls go through the database, which refuses to return rows the user shouldn't see, even if the AI asks for them.

See Roles & permissions → How Kiravy enforces this for the longer version.

Who can see your data

Within your firm:

Who	Can see
Partner	Every client in the firm
Manager	Every client in the firm
Senior / Junior	Only clients they're explicitly assigned to
Viewer	Only assigned clients, read-only
Client portal user	Just their own business + just their own uploads

Cross-firm: never. Even Kiravy staff with database access don't read your data routinely — see Kiravy team access below.

AI processing

When you chat with Kiravy AI, ask for a tax deductibility check, or upload a receipt for OCR, the underlying request leaves Singapore and goes to the AI provider's API:

• What's sent: only the specific data needed for the task — for a deductibility check, the vendor name, amount, account; for an OCR pass, the receipt image
• What's retained by the provider: nothing — by contract, the provider does not store the request data after the response is delivered
• What's logged on the Kiravy side: the token count and feature name for billing, but not the prompt body or the response

There's no fine-tuning on your data. No "your data trains a future model" footnote. The AI is used as a stateless processing call.

Retention

Records follow Malaysian Income Tax Act 1967 s. 82A — books and supporting documents are retained for 7 years after the year of assessment.

Kiravy's defaults:

Object	Default lifecycle
Transactions / receipts / invoices	Kept indefinitely (firm controls archival)
Soft-deleted rows	Hidden from UI, retained in DB indefinitely (for audit recoverability)
Archived clients	Hidden from default list, retained in DB indefinitely
Hard-deleted clients	Cascaded deletion; 7-day point-in-time backup at Supabase as a safety net
Deactivated members	Auth blocked; row + their authorship of past data preserved
Audit logs	Indefinite; we never trim
AI conversation history	Indefinite unless the user soft-deletes the thread
AI usage telemetry (ai_usage table)	30+ days for the in-product dashboard; archived older than that

The whole architecture leans toward don't lose data. Hard delete is a deliberate friction-heavy action — see Archive & delete for the full ceremony.

Data export — getting your data back

You can export at any time:

• CSV per surface — from Transactions, Customers, Suppliers, AR, AP tabs
• PDF P&L — via the report export button
• Receipt files — original images / PDFs can be downloaded individually (bulk export is on the roadmap)
• Full account export — contact support; we provide a ZIP with everything in CSV + PDF form within 5 business days

There's no vendor lock-in. Your data was always yours.

Data deletion on request

For PDPA (Personal Data Protection Act 2010) right-to-erasure requests:

1. The firm's Partner submits the request in writing to support
2. We confirm receipt within 48 hours
3. Soft delete is immediate via the UI (Partner can do it themselves — see Archive & delete)
4. Hard delete + backup scrub runs after the 7-day backup retention window expires — guarantees no recoverable copy
5. We send written confirmation when complete

For an individual's PII (e.g. a staff member's data after deactivation), support runs a PII-scrub that anonymises the row while preserving audit attribution by row ID.

Kiravy team access

Who at Kiravy can theoretically see your data:

Role	Routine access	When they'd touch it
Founders	Yes (database admin)	Investigating bugs you report, manual support requests
Future on-call engineers	Yes (database admin)	Incidents (production down, data corruption)
Customer success / support	No raw DB access	Use the admin UI which respects RLS

What we don't do:

• Routine browsing of customer data
• Selling, sharing, or aggregating customer data for any purpose
• Training models on your data
• Reading messages in AI conversations or chat with team members

Every Kiravy-team access to the database is logged. We'll surface that audit log to Partners in a future release.

Subprocessors

The third parties we depend on, with what each touches:

Subprocessor	What they see
Supabase	Everything (they host the DB + storage) — but encrypted at rest, and Kiravy controls the keys
The AI provider	Just the specific request payload (vendor name + amount for one classification, or one receipt image for OCR) — not retained
Sentry	Error stack traces — PII scrubbed before send
Postmark / SMTP	Outbound email content (invitations, password resets)
Cloudflare (DNS + CDN)	TLS termination; never sees decrypted content above the wire

We don't use third-party marketing trackers, ad networks, or analytics that fingerprint your visitors. PostHog (self-hosted) is for product analytics — anonymised events, not user-identifying ones.

Compliance posture today

What we claim:

• TLS everywhere
• Encryption at rest
• RLS-enforced tenant isolation
• Singapore data residency
• 7-day backup window
• Audit logging on key actions

What we're working toward (not certified yet):

• SOC 2 Type II — planned audit window in the next 12 months
• ISO 27001 — secondary; depends on demand
• Formal DPA template for enterprise customers — available on request today, productised soon

What we don't claim:

• PCI DSS (Kiravy doesn't process card data — that's the billing provider's domain)
• HIPAA (out of scope — we're financial, not healthcare)

If your firm's largest client requires a specific compliance attestation we don't yet have, talk to us — we'll know if it's on the roadmap or if it's not realistic for our stage.

Reporting a security issue

security@kiravy.com — please give us 90 days before public disclosure. We'll acknowledge within 48 hours and credit you (with permission) when the fix ships.

What's next

• Roles & permissions — the deeper take on RLS
• Source-agnostic data model — the storage shape
• Archive & delete — what hard-delete actually does