Skip to main content

1. Security model and scope

Clarity is a financial visibility and analysis platform. Our core security model is designed for data access, normalization, and reporting, not fund movement or custody.

Where providers support it, integrations are configured with read-only access scopes so account monitoring and reporting can happen without transfer permissions.

Security controls apply across application code, infrastructure, identity systems, data storage, and operational processes.

2. Data classes and handling

We treat data according to sensitivity and business purpose:

  • Account identity data: User profile and account metadata required for access control and support.
  • Financial records: Balances, transactions, and holdings used for analytics and reporting.
  • Sensitive credentials: Tokens or keys used to connect third-party services.
  • Operational telemetry: Logs and reliability signals used for monitoring, fraud prevention, and incident response.

Collection and processing are limited to what is needed to operate the service and meet legal obligations.

3. Encryption in transit and at rest

  • Traffic between clients and services is protected with TLS.
  • Sensitive integration credentials are encrypted before persistent storage, adding an application-layer control in addition to infrastructure protections.
  • Data stores and storage services use provider-managed encryption-at-rest controls.

Encryption is one layer of defense; it is combined with access controls, auditability, and operational monitoring.

4. Credential and key management

Secrets and API credentials are managed through controlled runtime environment configuration and least-privilege operational access.

  • Production secrets are not committed to source control.
  • Credential exposure events are treated as security incidents.
  • Key and token rotation is performed as needed for risk mitigation.

Users remain responsible for securing any third-party credentials they provide, including exchange API keys.

5. Access control and identity

Administrative and operational access follows least-privilege principles, with restrictions based on role and business need.

  • Production access is limited to authorized personnel and operational workflows.
  • Authentication controls are applied across administrative systems.
  • Access changes are reviewed and updated as responsibilities evolve.

6. Infrastructure and platform security

Clarity uses managed cloud infrastructure for application hosting, data storage, and service operations. Security posture includes provider controls and Clarity-managed controls.

  • Environment isolation between local development and production workloads.
  • Deployment workflows designed to reduce configuration drift and accidental exposure.
  • Baseline controls such as DDoS mitigation, network protection, and platform patching.

No infrastructure can eliminate all risk, so controls are designed as layered defenses.

7. Application security lifecycle

Security is integrated into feature development through code review, guardrails, and regression checks.

  • Automated checks run in CI to catch risky or inconsistent patterns.
  • Dependency updates and code changes are reviewed before production release.
  • High-impact surfaces receive focused validation before rollout.

8. Monitoring, logging, and alerting

Operational monitoring tracks application health, integration failures, error rates, and unusual access behavior.

  • Logs are used for debugging, reliability analysis, and security investigations.
  • Alerts are triaged according to severity and potential customer impact.
  • Critical incidents follow dedicated escalation workflows.

9. Incident response

When a security incident is suspected, Clarity follows a response flow covering containment, investigation, remediation, and communication.

  • Isolate affected systems or credentials.
  • Assess scope, root cause, and data impact.
  • Apply remediation and verify recovery.
  • Notify affected users and stakeholders when required by law or contract.

Post-incident review is used to improve controls and reduce recurrence risk.

10. Third-party and supply chain risk

Clarity depends on third-party services for core capabilities including connectivity, hosting, payments, and analytics.

  • Provider access is limited to required business functions.
  • Service disruptions and vendor incidents are treated as operational risk events.
  • Dependency and integration changes are evaluated for security impact.

11. Backup and continuity

We rely on managed infrastructure controls and operational processes to support service continuity and recoverability.

  • Provider-level backup and resiliency mechanisms support recovery workflows.
  • Incident procedures include service restoration and validation steps.
  • Major reliability events are reviewed for preventive improvements.

12. Customer security responsibilities

Customers can reduce risk by:

  • Using strong, unique credentials for Clarity and connected providers.
  • Enabling MFA on provider accounts whenever available.
  • Reviewing active integrations and removing unused connections.
  • Never sharing passwords, private keys, or plaintext API secrets with support.

13. Vulnerability reporting

If you believe you found a security issue, report it to legal@raintree.technology.

Include affected URLs, reproducible steps, estimated impact, and any proof-of-concept evidence. Do not include credentials or sensitive personal data in your initial report.

Good-faith reports help improve platform safety for everyone.

14. Compliance posture and updates

This page describes current practices and may be updated as controls, vendors, or legal requirements evolve.

For privacy and contractual terms, review Privacy Policy and Terms of Service.

Clarity does not currently claim independent security certifications on this page unless explicitly announced.

Need clarification? Contact the Clarity team.