Skip to main content
Waycore powers programmable execution across your bank accounts. That means every workflow, approval, and instruction must be secured to the same, or higher standard as your finance team. Below is the early description of our security posture as we move from alpha to a fully audited, production-grade platform.

​
Our Commitment at a Glance

Bank‑grade encryption

TLS 1.2+ in transit; AES-256 at rest with cloud-provider KMS isolation.

Delegated execution model

You create a dedicated bank user for Waycore; identical to hiring a treasury assistant, fully auditable and revocable.

Privacy by design

Only your team can view workflows and transaction data; no raw access for engineering.

Compliance roadmap

SOC 2 Type I (target Q1 2026) → Type II → ISO 27001 readiness.

​
The Waycore Execution Model

Waycore does not request banking credentials and does not impersonate operators. Instead, you provision Waycore as its own user in your bank, granting only the permissions required for your automations. Think of this as hiring a treasury assistant with:
  • Strictly scoped entitlements
  • Full auditability
  • Zero ability to exceed policy
  • Instant revocation
Operator Impact
  • Nothing circumvents existing bank controls.
  • All actions require workflow-level approvals inside Waycore.
  • Every action is attributable both in Waycore and your bank.

​
Data We Collect & Why

  • Delegated access tokens / bank user credentials you explicitly generate.
  • Transaction metadata needed to plan, schedule, and validate execution.
  • Workflow definitions & approvals to enforce policy.
  • Operational logs (IP, user ID, API usage) for security, debugging, and compliance.

​
Credential Handling & Delegated Access

Because Waycore is created as its own bank user: No shared secrets You issue credentials directly in your bank, not in Waycore. Encrypted at rest All delegated credentials are encrypted under a dedicated KMS key and never visible to any human. Short-lived sessions Execution sessions rotate automatically according to bank policy. Instant revocation Remove the bank user or revoke the credential → immediate loss of access.

​
Credential handling via Plaid

Connections that are created through Plaid’s/Finicity’s/MX’s OAuth/token flow. The short-lived public token is exchanged for a long-lived access token and written straight to our secrets vault, where it is encrypted at rest with AES-256 under a dedicated key in our cloud KMS. No human operators have read access to these secrets. All data access after that occurs through Plaid’s encrypted API, so raw credentials remain with the bank.

​
Execution Safety: Approvals & Policies

Waycore enforces a three-tier safety model: 1. Workflow approval gates
  • Role-based approval
  • Threshold and policy enforcement
  • Optional multi-step approvals
2. Bank-level enforcement All execution remains bound by your bank’s security model. 3. Immutable audit trail Every planning, approval, execution, and confirmation step is logged and tamper-evident.

​
Data Encryption & Storage

  • In transit: All external traffic is forced over HTTPS. We allow only TLS 1.2+ with forward-secret cipher suites and add the Strict-Transport-Security header so browsers automatically return over HTTPS.
  • At rest: Customer data lives on server-side–encrypted storage, protected with AES-256 keys managed by our cloud provider’s state of the art key-management service; backups and snapshots inherit the same encryption.
  • Back‑ups: Encrypted, geo‑redundant, with automated integrity checks and a 30‑day retention.

​
Access Controls & Monitoring

  • Least privilege & RBAC: IAM roles are scoped to the minimum set of resources and rotated quarterly.
  • Multi‑factor authentication: Required for all console and GitHub access; SSO for all employees.
  • Audit logging: Every action in our production environment is captured in a tamper-evident ledger. Logs are immutable, retained for 12 months, and continuously analyzed for anomalies.

​
Secure Development & Pen Testing

  • CI/CD security gates: Every build must clear static analysis in SonarQube and automated dependency-vulnerability scanning; pipelines halt on any critical finding.
  • Secrets management: Source code contains no secrets; runtime credentials are injected from our cloud secrets vault.
  • External penetration tests: Conducted twice per year; summary reports available to customers under NDA starting July 2025.

​
Privacy by Design

Before any prompt or transaction detail is used to fine‑tune models or build product analytics, we apply rigorous de-identification:

Strip direct identifiers

Remove names, account numbers, email addresses, and any other personally identifiable information.

Hash customer IDs

Hash customer IDs with salt and map to pseudonyms to prevent re-identification.

Aggregate data

Aggregate across at least ten (k ≥ 10) organisations to ensure statistical anonymity.

Apply differential privacy

Apply differential‑privacy noise (ε ≤ 1) to sensitive counts so no single user or company can be reverse‑engineered.

​
Compliance Roadmap

NIST CSF 1.1–aligned internal policies

Complete

SOC 2 Type I

In progress

SOC 2 Type II

Planned

​
Incident Response

We operate a 24×7 on-call rotation and commit to notify affected customers within 24 hours of confirming a breach of customer data. Monthly tabletop exercises ensure readiness. Our full Incident Response Plan is available on request.

​
Your Controls

  • Granular permissions: Disable analytics, revoke bank tokens or delete data in one click (Settings → Privacy).
  • Right to be forgotten: We will delete all personal data within 30 days of request or account closure.
  • Audit logs export: Enterprise plans can export six months of access logs via API.
Security is never “done.” If you spot something we can improve, drop us a note; responsible researchers earn thanks and swag.