"Bank-grade security" is the most abused phrase in financial technology. It appears on landing pages of platforms that store API keys in plain text, run unpatched servers in a rented rack, and let any staff member quietly edit any record. The phrase costs nothing to write; the engineering behind it costs a great deal. For a firm choosing infrastructure that will hold trader identities, payment keys and platform credentials, the difference is existential — a breach doesn't just leak data, it ends the brand.
So let's replace the slogan with a checklist. Security for a trading operation reduces to four concrete questions: how is data protected at rest, who can do what and is it recorded, who patches the servers and how fast, and how do people prove who they are. Here is what a serious answer looks like at each layer — and how eTrader and the Singuard CRMs answer.
Layer 1 — Encryption at Rest: AES-256-GCM, Not "Encrypted"
The word "encrypted" alone tells you nothing; the cipher and mode tell you everything. Singuard encrypts secrets at rest with AES-256-GCM — the Advanced Encryption Standard with a 256-bit key in Galois/Counter Mode. Two properties make this the mode that matters:
- 256-bit keys put brute force beyond computational reality — this is the key length used for genuinely sensitive material across banking and government.
- GCM is authenticated encryption — it doesn't just scramble data, it cryptographically verifies integrity on decryption. A ciphertext that has been tampered with, even by one bit, fails authentication and is rejected. Plain encryption hides data; authenticated encryption also proves nobody altered it.
What gets this treatment is exactly the material an attacker wants most: payment-processor keys, integration secrets and platform passwords. A database backup or stolen disk yields ciphertext, not credentials. Just as important is a policy detail: integration secrets are write-only after saving — staff can replace them, but never view them back. The deep dive is in encryption at rest, explained.
Layer 2 — Audited Actions: A Record Nobody Can Quietly Edit
Most damage in financial operations comes from inside the perimeter, not outside it — a rogue edit, a payout pushed through, a leverage change nobody remembers approving. The control that works is an audit log: every sensitive action — bans, payouts, phase changes, refunds, leverage edits, KYC decisions, rule changes — recorded with who did it and when, to a permanent, searchable log that no one can quietly edit.
Pair that with modular per-seat permissions and you have the internal-threat answer. In the Singuard CRMs, every page is granted per seat at None, Read, Write or Full — a support seat can hold Full on tickets and None on payment gateways; the permission model is enforced by the server, not by staff discipline, only owners grant permissions, and the admin account is invisible to staff lists entirely. An auditor — or a dispute — gets a definitive answer to "who did what, when" instead of a shrug. See compliance audit trails for how firms use this in practice.
The one-question vendor test: ask "show me the log entry created when a staff member changes a trader's leverage." If there's no such entry — or it can be deleted — the platform trusts its humans, and platforms that trust humans eventually get burned by one.
Layer 3 — Managed Patching: The Vulnerability Window Is the Risk
Almost no real-world breach uses an exotic zero-day; the overwhelming majority exploit known vulnerabilities on systems that simply hadn't been patched yet. That makes your patching cadence your true security posture — and it's where the self-hosted model quietly fails. A firm running its own white-label platform server owns the OS updates, the platform updates, the TLS configuration, the monitoring — usually assigned to whoever set the server up, patched whenever someone remembers. Every week of delay is an open window.
eTrader and the CRMs are fully managed: Singuard hosts, monitors, patches, backs up and scales the entire stack, continuously, across hundreds of clustered servers worldwide. Clustering adds resilience — if a node fails, another takes over — but the security dividend is cadence: patching is an operations discipline performed by the people who built the system, not a chore delegated to a distracted founder. And because every instance is managed, security improvements ship to every firm automatically, with no upgrade projects. This is one of the strongest — and least discussed — arguments in choosing a platform: when you compare vendors, you are choosing whose patching discipline your brand depends on.
Layer 4 — Identity: Passwordless Sign-in and Real 2FA
Credential theft is the front door of most account compromise, and the strongest defence is having fewer credentials to steal. The Singuard stack supports passwordless sign-in — a magic link or one-time code by email, so there is no stored password to phish or crack — alongside classic email + password and Google sign-in for those who want them. On top sits two-factor authentication by authenticator app (TOTP — Google Authenticator, Authy, 1Password) or email code, with email verification built in and a "sign out every device" control for the moment something looks wrong.
Client identity gets equal care where it's most sensitive: KYC documents are never exposed on a public link, and per-document review happens in a private compliance queue. The trader-facing details are covered in our 2FA guide.
Reading a Vendor's Claim: The Scorecard
| Question | Weak answer | Strong answer |
|---|---|---|
| Data at rest | "It's encrypted" | AES-256-GCM, named scope: keys, secrets, passwords |
| Internal actions | "Staff are trained" | Permanent audit log + server-enforced roles |
| Patching | "You manage your server" | Fully managed, continuous, by the vendor |
| Sign-in | Password only | Passwordless option + TOTP 2FA |
A vendor with strong answers in all four rows has earned the phrase "bank-grade." A vendor with slogans in any row is asking you to carry the risk they didn't engineer away.
"Bank-grade has to mean something: encrypted secrets, enforced roles, audited actions and infrastructure that assumes attack. Marketing can't patch architecture."
— Alex Onta, Executive Director, eTrader & Prop Firm CRM
Key Takeaways
- "Bank-grade" is testable: encryption cipher and scope, audit coverage, patching cadence and sign-in strength — demand specifics on all four.
- Singuard encrypts secrets at rest with AES-256-GCM — authenticated encryption that detects tampering, not just hiding.
- Every sensitive action lands in a permanent audit log behind server-enforced roles — the answer to the internal threat.
- Managed patching beats self-hosted every time: most breaches exploit known, unpatched vulnerabilities — your vendor's cadence is your posture.
Frequently Asked Questions
What Exactly Does AES-256-GCM Protect in the Singuard Stack?
The highest-value secrets: payment-processor keys, integration secrets and platform passwords, all encrypted at rest. GCM's authentication additionally guarantees the data hasn't been tampered with — and saved integration secrets can be replaced but never viewed back.
Do I Need My Own Security Team to Run eTrader or the CRMs?
No. The stack is fully managed — Singuard hosts, monitors, patches, backs up and scales everything on clustered infrastructure, and security improvements roll out to every firm automatically. Your team runs the firm, not the servers.
Can My Traders Use Two-Factor Authentication?
Yes — TOTP authenticator apps or email codes, on top of passwordless sign-in via magic link or one-time code, with email verification and a "sign out every device" control. Details in passwordless authentication.