Information Handling Statement

Our Approach to User Information

sarynthivo operates a financial management service focused on helping Australian households track their monthly spending, set realistic budgets, and work toward savings goals. When you interact with our platform—whether creating an account, linking bank feeds, or setting up budget categories—certain details about you and your financial activity become necessary for the service to function properly.

This document explains what we learn about you, why that information matters to us operationally, where it goes, how long we keep it, and what control you retain over it. We've structured this explanation around user touchpoints rather than following the typical legal framework because we think it's easier to understand when organized by what you're actually doing.

What We Learn When You Register

Account creation asks for basic identifying elements: full name, email address, phone number, and your residential postcode. These serve different operational needs. Your name appears in communications and helps us verify identity if you contact support. Email becomes the primary channel for system notifications—password resets, budget alerts, monthly summaries. The phone number exists as a backup contact method and supports two-factor authentication if you enable it.

Your postcode serves two purposes. First, it helps us understand regional usage patterns. Second, and more practically, it allows the system to suggest relevant local expense categories. Someone in metropolitan Sydney might see different retail or transport suggestions compared to someone in regional Queensland.

Authentication Details

We store password information in hashed form—meaning we can verify what you enter matches what was set, but we can't reverse-engineer the original password from what's stored. If you forget your password, we can't retrieve it. We can only let you set a new one.

Login sessions are tracked through tokens that expire after periods of inactivity. This prevents someone accessing your account if you leave a device unlocked. We record when authentication attempts occur and from which IP addresses. Failed login attempts trigger temporary account locks as a security measure.

Financial Account Connections

The core functionality revolves around automatic transaction imports. When you authorize a connection to your bank or credit card, we use third-party aggregation services to establish secure read-only access to transaction history. We don't store your banking login credentials. Instead, the aggregation service (which you separately authorize) provides us with tokenized access to transaction feeds.

Transaction records include merchant identifiers, purchase amounts, transaction timestamps, and location data when provided by financial institutions. Our system processes this to categorize spending automatically, flag unusual patterns, and calculate budget adherence.

What Gets Derived From Transactions

Beyond raw transaction data, our algorithms generate insights: spending trends over time, category comparisons, recurring payment identification, income regularity assessments. These analytical outputs remain tied to your account and drive personalized budget recommendations.

We also identify merchant patterns. If transactions show consistent spending at particular retailers or service providers, the system learns these patterns to improve future categorization accuracy. This learning happens at the individual account level, though anonymized pattern data may inform broader categorization models.

How Budgets and Goals Are Handled

When you establish spending limits, savings targets, or financial goals within the platform, you're creating a framework that the system uses to evaluate your transaction activity. These preferences become part of your profile data. Goal structures might include target amounts, timelines, associated categories, and priority rankings.

Budget modifications—when you adjust limits or restructure categories—get logged with timestamps. This history allows you to review how your financial planning approach has evolved. It also helps our support team troubleshoot if budget calculations appear incorrect.

Custom categories you create reflect personal spending patterns that standard classifications might not capture. These become part of your account's unique configuration. We occasionally review anonymized custom category data to identify common needs that might warrant adding to our standard taxonomy.

Communication Records

Every interaction through our support channels—whether email, in-platform messaging, or phone calls—generates records we maintain for service continuity and quality purposes. Support conversations often reference specific financial situations, budget questions, or technical issues with bank connections.

These exchanges may reveal sensitive financial circumstances. Support staff access them only when assisting you directly. We use them to track issue resolution, identify recurring technical problems, and train support personnel on common scenarios.

Outbound Notifications

The platform sends various alerts: budget overage warnings, unusual spending notifications, bill reminders, weekly summaries. These communications originate from automated systems triggered by transaction analysis. Records of what notifications were sent and when help prevent duplicate alerts and allow you to review notification history.

You control notification preferences through account settings. Changes to these preferences take effect for future communications but don't retroactively affect what was previously sent based on earlier settings.

Technical Interaction Data

Platform usage generates technical footprints. Server logs capture request timestamps, response codes, page views, feature usage frequency, session durations, and error occurrences. Device characteristics—browser type, operating system, screen resolution—help optimize interface presentation and identify compatibility issues.

IP addresses appear in connection logs. We use these for security monitoring, identifying unusual access patterns, and supporting geographic load distribution. They help detect if account access is occurring from unexpected locations, which might indicate unauthorized access.

Performance Monitoring

Application performance metrics—page load times, database query speeds, API response latency—get collected to maintain service quality. These measurements include identifiers linking them to specific user sessions so engineers can diagnose individual performance complaints.

Error tracking systems capture failed operations along with context about what you were attempting. If a budget calculation fails or a bank sync errors out, the system logs relevant state information to facilitate troubleshooting. These technical records might inadvertently contain fragments of financial data being processed when the error occurred.

Where Information Moves Outside sarynthivo

Several operational necessities require sharing data with external entities. These aren't discretionary transfers—they're fundamental to service delivery or legal compliance.

Legal and Regulatory Disclosures

Australian financial regulations may compel disclosure under certain circumstances. Valid legal process—court orders, subpoenas, regulatory inquiries—can require us to produce account records. We don't proactively volunteer user data to authorities, but we comply with properly served legal demands.

Suspected illegal activity triggers different protocols. If transaction patterns suggest money laundering, fraud, or other financial crimes, we may report to relevant authorities as required under anti-money laundering legislation. These reports happen without prior notification because legal restrictions prevent us from alerting subjects of such reports.

Business Transactions

Should sarynthivo undergo acquisition, merger, or restructuring, user data becomes part of transferred business assets. The acquiring entity would inherit existing commitments regarding information protection, though their broader privacy practices might differ from ours. We'd notify users of such ownership changes.

Protection Measures and Residual Risks

Financial data handling demands robust security architecture. We implement multiple defensive layers: encrypted transmission channels for all network communications, encrypted storage for sensitive database fields, access controls limiting which team members can view which data types, automated threat detection systems, regular security audits, and penetration testing by external specialists.

Employee access follows least-privilege principles. Support staff see only what's necessary to resolve your specific inquiry. Engineers working on system improvements typically interact with anonymized or synthetic data sets. Database administrators who manage infrastructure have technical access but face strict usage policies and audit logging.

We maintain incident response protocols for security events. If unauthorized access occurs, we assess scope, contain the breach, determine what data was affected, notify impacted users, and report to regulators as required. The timeline for these actions depends on event complexity, but legally mandated notifications follow statutory deadlines.

Your Security Responsibilities

Account security depends partly on practices we control and partly on your behavior. Strong, unique passwords significantly reduce unauthorized access risk. Two-factor authentication adds meaningful protection. Avoiding password reuse across services prevents credential stuffing attacks. Logging out on shared devices prevents casual access by others.

Phishing remains a persistent threat. We won't email requesting your password or asking you to click links to verify account details. Suspicious communications claiming to be from sarynthivo should be forwarded to our security team rather than acted upon.

Retention Duration and Deletion

Different data categories follow different retention schedules based on operational necessity and regulatory requirements.

Active Account Data

While your account remains active, we maintain all associated information indefinitely. Transaction history, budget configurations, historical analyses, and communication records accumulate over time. This continuity enables long-term trend analysis and preserves your financial history for as long as you find it useful.

Inactive Accounts

Accounts with no logins for 24 consecutive months enter inactive status. We send notifications before this occurs. Inactive accounts remain accessible if you return, but after 36 months of inactivity, accounts may be deleted entirely. This prevents perpetual storage of potentially obsolete information.

Deletion Requests

You can request account closure and data deletion at any time through account settings. This triggers a 30-day grace period during which you can reverse the decision. After that window, we delete your transaction history, budget data, profile information, and most associated records.

Some residual data persists beyond account deletion. Financial records required for tax purposes or legal compliance may be archived separately for seven years per Australian tax law. Anonymized data derived from your usage but no longer linked to identifying details might remain in aggregate analytics. Communication records involving support or legal interactions may be retained in those separate systems.

Backup Retention

System backups create temporal copies of all data. These backups cycle on rolling schedules—daily backups retained for one week, weekly backups for one month, monthly backups for one year. Deleted data may persist in backups until those backup cycles naturally age out. Immediate deletion from all backups isn't technically feasible in distributed cloud environments.

Legal Foundations for Processing

Australian Privacy Principles under the Privacy Act 1988 govern how we handle personal information. Several legal bases justify different processing activities:

• Contractual necessity: Processing required to deliver the budgeting service you've signed up for—transaction analysis, budget calculations, notifications—falls under contract performance.
• Consent: Certain optional features like connecting financial accounts or receiving promotional communications rely on explicit consent you provide through interface actions.
• Legal obligation: Compliance with financial regulations, tax reporting requirements, and valid legal process compels some data handling regardless of other considerations.
• Legitimate interests: Operational activities like security monitoring, fraud prevention, service improvement, and technical troubleshooting serve legitimate business needs balanced against user privacy interests.

When processing relies on consent, you maintain the right to withdraw that consent. Doing so may limit service functionality if the processing was integral to features you were using. For instance, revoking bank connection authorization means transaction imports stop, which fundamentally alters how the budgeting platform functions.

Your Control and Access Rights

Australian privacy law grants specific rights regarding personal information organizations hold about you. How these apply in practice:

Access and Portability

You can request copies of data we maintain about you. The platform provides self-service export functionality generating downloadable files containing your transaction history, budget configurations, and account details in structured formats. For information not available through automated export—like support conversation histories or technical logs—email requests to our privacy team trigger manual compilation.

Access requests are generally fulfilled within 30 days. Complex requests requiring extensive technical retrieval might take longer, though we communicate timelines proactively.

Correction

If you identify inaccurate information, you can correct most profile details directly through account settings. Transaction data reflects what financial institutions reported, so corrections to transaction details need to occur at the source bank or card issuer. Once they update their records, corrected information flows through subsequent data syncs.

For data you can't self-correct, contacting support initiates verification and update processes. We may request documentation supporting requested changes to prevent fraudulent modifications.

Restriction and Objection

You can object to certain processing activities. Marketing communications can be disabled through preference settings. Some algorithmic analyses like spending pattern predictions can be turned off, though this reduces personalization value. Core functional processing necessary for service delivery can't be selectively disabled while maintaining an active account—at that point, account closure becomes the mechanism for stopping processing.

Complaint Escalation

Concerns about how we handle your information should initially be directed to our privacy team at support@sarynthivo.sbs. We investigate complaints and respond with findings and corrective actions if needed.

If our response doesn't satisfy you, external escalation options exist. The Office of the Australian Information Commissioner (OAIC) handles privacy complaints about organizations subject to the Privacy Act. They can investigate and issue determinations. Contact details: 1300 363 992 or enquiries@oaic.gov.au.

Changes to These Practices

Service evolution may necessitate updates to how we handle information. New features might require processing additional data types. Regulatory changes could impose different retention requirements. Technical infrastructure updates might alter where data is stored.

Material changes trigger email notifications to active users. "Material" means alterations affecting what information we collect, how we use it, or who we share it with. Minor clarifications to language or updates reflecting unchanged existing practices don't require notification.

Continued platform use after notification of changes constitutes acceptance of the updated terms. If changes are unacceptable to you, account closure before the change effective date allows you to exit under previous terms.

This document carries a version date at the top. The current version applies to all information handling from its effective date forward. Previous versions govern data collected and processed under those earlier frameworks.