Security Practices

Quick summary. Read the full policy below for the complete terms.

Document owner

FinSync LLC (operating as Raintree Technology) security and compliance team.

Contact + response

Email legal@raintree.technology for security or compliance questions. We acknowledge vulnerability reports within 5 business days.

Access model

Read-only. Clarity can see your financial data but can never move funds or change your accounts.

Encryption

TLS in transit, authenticated encryption for stored credentials, encryption at rest for everything else.

Credential storage

API keys and secrets are encrypted before storage. Never in source control.

Incident response

Defined response flow: contain, investigate, remediate, notify affected users.

Vulnerability reporting

Found something? Email legal@raintree.technology with reproduction steps and estimated impact.

SOC 2 status

As of March 10, 2026, Clarity has not completed a SOC 2 attestation. Controls are aligned to SOC 2 Trust Services Criteria. Progress updates live in Compliance posture and updates.

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.

As a service that aggregates financial data from banks and brokerages, Clarity's security program uses the FTC Safeguards Rule under the Gramm-Leach-Bliley Act (GLBA) as a reference point for controls such as access management, encryption, risk assessment, and incident response. This page is not a certification or legal opinion.

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.

• Traffic between clients and services is protected with TLS 1.2 or higher.
• 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.

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.

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.
• Personnel with access to production systems receive security awareness guidance as part of onboarding and on an ongoing basis.

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.

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.
• Change management processes govern production deployments, including review, approval, and rollback procedures.

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.

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.

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.
• New vendors and subprocessors are assessed for security posture, data handling practices, and compliance commitments before onboarding.

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.

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.

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.

13.1 Safe Harbor

We will not pursue legal action against individuals who report vulnerabilities in good faith, follow this disclosure policy, and avoid actions that harm our users or service availability. Good-faith security research conducted under this policy is considered authorized.

13.2 Scope

In scope: The Clarity web application (app.useclarity.app), public APIs, and authentication flows.

Out of scope: Third-party services (Plaid, Stripe, OpenAI), social engineering attacks, denial-of-service testing, and physical security.

13.3 Response Timeline

We will acknowledge receipt of your report within 5 business days and provide an initial assessment within 15 business days. We will keep you informed of remediation progress for confirmed issues.

13.4 Bug Bounty

We do not operate a formal bug bounty program at this time. We appreciate and publicly acknowledge (with your permission) valid reports that lead to security improvements.

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.