For [CHURCH NAME]'s tech, security & governance team
Security & Privacy
Designed security-first
We don't hold what we don't need.
No raw bank account numbers. No credit card numbers. No individual member transactions in pastor dashboards. All data encrypted at rest (AES-256) and in transit (TLS 1.3).
Plaid
Read-only bank connectivity. Same trust layer as Venmo, Robinhood, EveryDollar. SOC 2 Type 2 + ISO 27001 certified. We never see or store bank credentials.
Stripe
PCI DSS Level 1 — the highest tier of card-data compliance. We use Stripe Elements / Checkout, so card numbers never touch our servers. Stablish operates at PCI DSS SAQ-A scope — the lowest reviewer burden possible.
Encrypted End-to-End
Encrypted at rest (AES-256) and in transit (TLS 1.3). Passwords and access secrets are hashed — never stored in plain text. The data your reviewers care most about (account numbers, card numbers) never touches our servers — Plaid and Stripe hold those by architecture.
What we store · what we don't
What we never store
- Bank account numbers (Plaid holds these)
- Credit card numbers (Stripe holds these)
- Plain-text passwords or bank credentials
- Individual member transactions in any pastor dashboard
- Member data sold or shared with third parties — ever
What we do store (encrypted at rest)
- Member profile (name, email, phone, church)
- Plaid connection tokens used to fetch transactions
- Member transaction data for Money Map coaching
- Aggregate giving health surfaced to the church
- Coaching activity and Money Map history per member
The pastor / member boundary
This is the most important line in Stablish's design. Pastors never see individual member transactions.
| What pastors see | What stays out of the pastor view |
|---|---|
| Aggregate giving health trends | Individual spending categories |
| At-risk recurring givers (lapsed-pattern flags) | What members purchased, where, how much |
| First-time givers (to thank pastorally) | Member's debt, savings balances, income |
| Giving rhythm aggregates | Money Map sub-scores or coaching activity |
The compliance stack
| Layer | Vendor | Compliance |
|---|---|---|
| Bank connectivity | Plaid | SOC 2 Type 2 · ISO 27001 |
| Payments & card data | Stripe | PCI DSS Level 1 |
| Compute & data (US) | AWS | SOC 2 · ISO 27001 · PCI DSS · HIPAA |
| Edge, CDN & WAF | Cloudflare | SOC 2 Type 2 · ISO 27001 · PCI DSS |
| Stablish | — | SOC 2 Type 2 — targeting late 2027 · PCI DSS SAQ-A (no card data on Stablish servers) |
Built on the standard enterprise rails your IT team already trusts: Flutter (mobile) → Python (backend) → AWS Postgres (data), with Cloudflare at the edge. The boring, proven choices — by design.
On SOC 2: we operate to SOC 2-aligned controls today — the policies, monitoring, and access patterns described in this doc. Formal Type 2 audit and certification will follow our funding round, targeted late 2027.
What's in place today: MFA on all internal systems and full audit logs on every production data read and write. Our small engineering team has standing access to PII (name, email, phone) and Plaid connection tokens for support and debugging — and that access scope is architecturally limited: no one at Stablish can see bank account numbers (Plaid holds them) or credit card numbers (Stripe holds them). Formal RBAC and just-in-time production access are on our near-term roadmap as we scale beyond the founding team.
"This isn't a typical startup."
Stablish's product leadership comes from a decade-plus VP of Product role operating under enterprise security scrutiny. Our security advisor currently leads SOC 2 and ISO compliance programs for large financial institutions and architected our security model from day one. We treat security like the institutions we serve — because we've been them.
Our philosophy
Open by design.
Not every integration is pre-built today — but if your stack needs it, we'll build it. The openness is the principle; custom build work may have a scope-dependent cost.
- Open APIs — endpoints available today; new endpoints built on request.
- SDKs on request — mobile or web SDKs built to your spec; scope-dependent cost may apply.
- White-label — open to discussion at additional cost.
- Custom integrations welcome — Pushpay, Tithe.ly, your ChMS — we'll build for your stack.
- We're an engagement layer, not a system of record. Your giving platform stays yours.
- No lock-in. Annual contracts. Full data portability. Leave any year.
We'll walk your team through anything in detail — architecture, data flows, vendor diligence — live with engineering on the call.
[phone]