Security architecture
Protection, control, and transparency.
Protection, control, and transparency.
Funds stay on your exchange.
MyZiggy is a decision and execution discipline layer — not a custodian, broker, or exchange. We never hold user funds, never request withdrawal permissions, and never move money. This page describes how we protect data, API connections, and trade execution end-to-end.
Funds never leave your exchange
Trade-only API permissions
Encrypted in transit
You confirm every trade
Security philosophy
Three principles that shape every design decision.
Security at MyZiggy is not a posture or a checklist. It is a structural choice — about what the platform is allowed to do, what it is allowed to know, and what it leaves under the user's direct control.
01 · Decision engine, not custodian
We never hold funds.
MyZiggy ranks setups, structures trades, and routes orders to your exchange after you confirm. Your capital stays in your exchange account at all times. We are not registered as, and do not operate as, a broker, dealer, exchange, or custodian.
02 · User control is non-negotiable
You confirm every execution.
Every trade requires explicit user approval before any order is sent. Risk parameters, position size, and the decision to enter are yours. You can revoke API access from your exchange at any time without contacting us.
03 · Risk-aware by design
Built to fail safe.
The system is designed so that the worst-case behaviour of any single component is bounded. We route through trade-only API keys, so even a full compromise of MyZiggy infrastructure cannot withdraw funds from your exchange.
Data protection
What we collect, how it travels, where it lives.
We aim to handle the minimum data needed to operate the platform, and to handle that data in transit and at rest with current industry-standard practices.
Encryption in transit
All connections to and from MyZiggy use HTTPS over TLS. Plaintext HTTP is rejected.
- HTTPS / TLS 1.2+ on every page, API call, and webhook.
- HSTS with strict transport security on the public domain.
- Outbound calls to exchanges run over the exchange's authenticated TLS endpoints only.
Secure API connection handling
Exchange API credentials are stored encrypted and used only to place the trades you approve.
- Credentials are encrypted at rest with industry-standard symmetric encryption.
- Decryption keys are isolated from the application database.
- Keys are accessed only by the execution service, only at the moment a confirmed order is placed.
- Users can rotate or revoke keys at any time from their exchange dashboard.
No unnecessary data storage
We collect what is needed to run the service. We do not store what we do not need.
- We do not request, store, or process bank or card details directly — payments are handled by our PCI-compliant payment processor.
- We do not store exchange withdrawal addresses.
- Account-level data is retained only while the account is active, plus the period required by applicable law.
Principle of least privilege
Each internal service has access only to the data and operations it needs.
- Service-to-service permissions are scoped to the narrowest role that lets the service do its job.
- Engineering access to production data is limited to named individuals on a need-to-access basis.
- Privileged actions are logged and reviewed.
Infrastructure security
Where MyZiggy runs.
The platform is hosted on a leading commercial cloud provider with strong physical, network, and identity controls. We treat the cloud provider as part of our shared-responsibility model — we own the configuration, code, and access controls layered on top.
Cloud hosting
Production workloads run on Amazon Web Services (AWS).
- AWS provides physical security, hardware isolation, and infrastructure-level protections.
- We deploy across availability zones to limit single-zone failure impact.
- Public endpoints sit behind a managed web application firewall and DDoS protection.
Isolated services and environments
Production, staging, and development are fully separated.
- Network-level isolation via private subnets and security groups.
- The decision engine, scoring engine, execution engine, and data ingestion run as separate services with distinct credentials.
- Production data is not used in development or test environments.
Access control
Strong identity controls govern who can reach what.
- Multi-factor authentication required for all administrative consoles.
- Role-based access scoped to job function. No shared admin accounts.
- Access is reviewed and revoked when roles change.
Monitoring and alerting
Continuous visibility into what the platform is doing.
- Centralised logging for application, infrastructure, and access events.
- Automated alerts for anomalies, error spikes, and unexpected execution patterns.
- System health is published on the public System Status page.
Application security
How the application protects accounts and sessions.
Most attacks against fintech web applications target accounts, sessions, and inputs. These are the controls we apply at that layer.
Authentication and sessions
User accounts and active sessions are protected with current best practices.
- Passwords are hashed with a modern memory-hard algorithm. Plaintext passwords are never stored or logged.
- Optional two-factor authentication (TOTP) on user accounts.
- Session tokens are short-lived and scoped to a single device. Sessions can be revoked from the user's account settings.
- Sensitive actions (changing API keys, exporting data) require re-authentication.
Rate limiting and abuse controls
Public and authenticated endpoints are rate-limited to slow brute force and abuse.
- Login and password-reset endpoints are rate-limited per IP and per account.
- Repeated failed authentications trigger temporary lockouts and alerts.
- API endpoints have per-user quotas to limit blast radius from compromised tokens.
Common web attack mitigations
Standard defences against the most common application-layer attacks.
- Parameterised queries and input validation to mitigate SQL injection.
- Output encoding and a strict Content Security Policy to mitigate cross-site scripting (XSS).
- CSRF protections on state-changing requests.
- Dependencies are continuously scanned for known vulnerabilities and patched on a regular cadence.
Secure development practices
Security is part of the engineering workflow, not an afterthought.
- Code changes are peer-reviewed before they reach production.
- Automated static analysis and secret scanning on every pull request.
- Production secrets are managed through a dedicated secrets store, not source code.
Trading safety controls
What the execution layer will and will not do.
The execution side of MyZiggy is intentionally narrow. It can route the trades you confirm. It cannot trade for you, lever you up, or override your judgement.
No forced trades
No trade is placed without an explicit user confirmation.
- Every order requires the user to review entry, stop, and targets and approve before routing.
- The platform never auto-enters trades, never auto-recovers from losses, and never opens positions in the background.
Rules-based execution
Once you confirm, the trade plan runs exactly as approved.
- Stop-loss and take-profit orders are placed exchange-side at the moment of confirmation.
- The platform does not move stops adversely, average down, or modify the approved plan after execution.
- Users can close, modify, or cancel positions at any time, either inside MyZiggy or directly on the exchange.
Risk filtering via scoring
Setups that fail structure and confluence checks are not surfaced for execution.
- The scoring engine ranks setups across a defined set of structural, momentum, and risk criteria.
- Setups that score below a minimum quality threshold are flagged or excluded from the executable list.
No over-leverage logic
The platform does not push users into outsized positions.
- Position sizing respects user-defined risk-per-trade settings.
- The platform does not include martingale-style sizing, no auto-pyramiding into losers, no automatic leverage increases after losses.
- Maximum leverage is bounded by the exchange's account-level limits, which the user controls.
User responsibility
What you control. What you should configure.
Some of the most important security boundaries are set by you, on your exchange. Here is what we recommend, and what we will never ask for.
Capital
Your exchange
Funds remain in your exchange account at all times.
Decision & routing
MyZiggy
Ranks setups, structures the trade, places confirmed orders. Holds no funds.
User
You confirm
Every trade reviewed and approved before any order is sent.
API permissions to enable
- Read account data — to display balances, positions, and order status.
- Place and cancel spot/derivative trades — required for the platform to route confirmed orders.
- Restrict API by IP — strongly recommended. Restrict the API key to MyZiggy's published egress IPs.
API permissions you must NOT enable
- Withdraw funds — MyZiggy never asks for or uses withdrawal permissions. Leave this disabled.
- Internal transfers between exchange accounts — not required by the platform.
- Sub-account creation or management — not required by the platform.
Things only you can do
There are a few controls that, by design, sit outside MyZiggy.
- Enable two-factor authentication on your exchange account. This is your single most important control.
- Choose your risk-per-trade and overall exposure limits. The platform does not raise these for you.
- Decide whether to confirm any individual trade. The platform may rank a setup highly; the decision to take it is always yours.
- Rotate or revoke API keys at any time directly from your exchange. You do not need to contact us first.
Disclaimer
What MyZiggy is — and what it is not.
Important notice
MyZiggy does not hold user funds. The platform is not a broker, dealer, exchange, custodian, or registered investment advisor. Capital remains in the user's own exchange account at all times. API access used by the platform is trade-only and never includes withdrawal permissions.
No guarantees of performance. The platform provides decision support and execution discipline. It does not promise, guarantee, or imply any specific trading outcome, return, profitability, or risk-adjusted performance. Past performance of any setup, ranking, or strategy is not indicative of future results.
Tool, not financial advice. Nothing on this page or anywhere on the platform constitutes financial, investment, tax, or legal advice. Users are solely responsible for their own trading decisions, sizing, and risk management. Crypto trading involves substantial risk, including the possible loss of all capital committed.
Security is shared. The controls described on this page are part of a shared-responsibility model. Account-level security on the exchange, API permission scoping, and the decision to confirm any individual trade are the user's responsibility.
This page is a description of MyZiggy's security architecture and operating model. It is not a contract, certification, or warranty. Specific implementation details may evolve as the platform improves; material changes will be reflected here.