Company · Technology & Security
Technology & Security
Engineering secure, resilient and observable technology platforms for real-world business environments.
How to read this page. It describes how Vianmax™ designs, builds and operates platforms. It is not a certification or an audit report. The controls that apply to a particular platform depend on its requirements, deployment and hosting, and are set out in that project's technical documentation. Nothing here discloses credentials, infrastructure details or internal procedures.
01 · Engineering principles
Security is not a layer added after development.
It is considered throughout the technology lifecycle: in the architecture, in how code is written and reviewed, in how access is granted, in how data is stored and in how the running system is watched. These are the ten concerns every Vianmax™ platform is designed around.
Secure architecture
Trust boundaries, data flows and failure modes are decided in the architecture, before the full build starts.
Secure development
Typed interfaces, automated tests and code review on every change.
Identity & access
Every request is authenticated and authorised. Access follows least privilege.
Data protection
Data is collected only where needed, stored in defined places and reached only through controlled paths.
API security
Services communicate through defined, validated interfaces, never by reaching into each other’s data.
Observability
Logging, monitoring and alerting are part of the build, not an afterthought.
Auditability
Consequential actions leave a record that can be reviewed later.
Resilience
When something fails, the system is designed to stop safely and report, not to guess.
Controlled deployment
Changes move through separate environments and reach production deliberately.
Continuous improvement
Incidents, reviews and testing feed back into the design.
02 · Security architecture
Controls at every layer, not only at the edge.
A request passes several independent checks between the user and the data. If one control fails or is misconfigured, the next still applies.
Figure 1 · Layered security architecture
- User / clientBrowser or app. Treated as untrusted: nothing it sends is accepted without checks on the server.
- Identity & authenticationEstablishes who is making the request before anything else happens.
- Authorisation / RBACDecides what that identity may do, by role and permission, on every request.
- API securityValidates each request, limits request rates and returns errors that reveal nothing internal.
- Application servicesBusiness logic, running with only the access it needs.
- Data access controlsServices reach data through defined paths and scoped database accounts, not shared credentials.
- Protected data storesProduction data stores with restricted access, encrypted where the platform and hosting support it.
- Infrastructure securityHardened hosts, restricted network access and separated environments.
- Monitoring, logging & auditRecords what happens at every layer, so events can be detected, investigated and explained.
03 · Identity & access management
Least privilege, by default.
Each person and each service gets the access its job requires and nothing more. Access that is not needed is not granted, and access that is no longer needed is removed.
Authentication
Users prove who they are before any protected action. Credentials are verified on the server, never in the browser.
Authorisation
Every request is checked against what that identity is permitted to do, in authorisation middleware rather than scattered through the code.
Role-based access control
Permissions are grouped into roles that match real responsibilities, so access is granted by role and reviewed by role.
Session management
Sessions and access tokens should have limited lifetimes, be revocable, and be transported and stored securely.
Access policies
Rules for who may do what are defined per platform and documented, not decided ad hoc.
Privileged access
Administrative capability is separated from day-to-day use and limited to the people who need it.
Service-to-service authentication
Internal services authenticate to each other too. A request is not trusted because it comes from inside.
Access review
Access is reviewed when people or responsibilities change, and removed when it is no longer needed.
04 · Data protection
Protect what is kept. Keep only what is needed.
The approach below applies to every platform. How each measure is implemented depends on the deployment and the hosting environment.
Encryption in transit
Production deployments should use encrypted transport between users, services and data stores.
Encryption at rest
Data stores and backups are encrypted where the platform and hosting support it.
Database access controls
Each service is designed to use its own scoped database account, rather than shared administrative credentials.
Secrets management
Credentials and tokens stay server-side, out of front-end code and source files, and are provided to services at run time.
Data minimisation
A platform collects the data its function needs. Fields without a purpose are not collected.
Backup protection
Backups are access-restricted and treated with the same care as the live data.
Data retention
Retention follows the platform’s purpose and applicable law, and is set out in its privacy terms.
Secure handling
Personal and financial data is not copied into logs, test systems or messages where it is not needed.
05 · API security
Every interaction goes through a defined interface.
APIs are the only way the parts of a platform talk to each other. That makes them the place where identity, permission and validity are checked.
Figure 2 · Controlled communication in AlphaSync
- 01FrontendReact web interface
- 02API layerFastAPI services
- 03Application servicesBusiness logic
- 04Strategy · risk · ordersDomain services
- 05Data layerMySQL
Authentication
Every call carries a verified identity.
Authorisation
Checked per endpoint and per resource.
Input validation
Every field is typed and validated before use.
Request validation
Malformed or unexpected requests are rejected early.
Rate limiting
Limits protect the platform and downstream services from overload.
Secure error handling
Errors are logged in full internally and reported generically to the caller.
Versioning
Interfaces change in versions, so clients are not broken without notice.
Service isolation
A fault or compromise in one service is contained to that service.
Logging
Requests and outcomes are recorded for investigation.
Monitoring
Error rates and response behaviour are watched continuously.
06 · Role-based access & audit trails
Who can do what, and a record of what was done.
Institutions need to separate duties and to answer, later, who did what and when. Role-based access provides the first; an audit trail provides the second.
Roles and permissions are defined for each product and deployment, to match how the organisation actually works. In AlphaSync, permissions are set at user level, and each broker connection is authorised by the account holder.
Audit records are designed to be written by the platform, not edited by users, and kept for review. Actual records belong to the customer and are never published.
| Event category | Examples |
|---|---|
| Authentication | Sign-ins, failures, sign-outs |
| Authorisation changes | Roles or permissions granted, changed or removed |
| Configuration changes | Settings, limits and integrations changed |
| Administrative actions | Actions taken with elevated access |
| User actions | Consequential actions taken in the platform |
| System events | Start-up, shutdown, failures and recoveries |
| Trading events | In AlphaSync: every signal, order and fill |
07 · Logging & observability
A running system you can see into.
Logging, monitoring and alerting are part of the build. They are how problems are found before users report them, and how they are explained afterwards.
Figure 3 · From signals to response
- 01ApplicationsServices and APIs
- 02Logging & metricsStructured events and measurements
- 03ObservabilityOne place to see system state
- 04AlertingThresholds and anomalies
- 05OperationsPeople who act
- 06Incident responseContain, recover, review
What is captured
- Application logs
- API logs
- Security events
- Authentication events
- Infrastructure metrics
- Application metrics
- Health checks
- Error tracking
- Performance monitoring
- Operational alerts
- Faster detectionProblems are seen when they start, not when a user reports them.
- TroubleshootingLogs and metrics show what happened, in what order.
- Performance analysisSlow paths are measured rather than guessed.
- Security investigationAuthentication and access events can be reconstructed.
- Operational accountabilityAlerts and responses should leave a record.
08 · Backup & disaster recovery
Planned recovery, not improvised recovery.
Recovery objectives are defined according to deployment requirements and business criticality, and agreed with the client. We do not publish generic recovery figures, because they depend on each deployment.
Automated backups
Scheduled backups of data stores where configured, at a frequency set by the deployment’s requirements.
Backup integrity
Backups are only useful if they restore. Restores should be tested, not assumed.
Recovery procedures
Documented steps for restoring each part of the platform.
Disaster recovery planning
What happens if a whole environment is lost is decided in advance.
Failure isolation
Components are separated so that one failure does not take down the rest.
Service restoration
Services are brought back in a defined order, with checks at each step.
Data recovery
Data is restored to a known, consistent point, and reconciled where external systems are involved.
Business continuity
The plan covers people and communication, not only systems.
09 · Infrastructure & deployment
Separate environments, deliberate releases.
Changes move through defined environments. Production is reached on purpose, with a way back.
Figure 4 · Environment promotion
- 01DevelopmentWhere changes are built and reviewed
- 02TestingAutomated and functional tests
- 03StagingProduction-like validation
- 04ProductionControlled release
Containerised deployment
Services are packaged in containers where applicable, so each environment runs the same build.
Environment separation
Development, test, staging and production do not share data or credentials.
Configuration management
Configuration is kept outside the code and versioned per environment.
Secrets management
Credentials are injected at run time, never committed to source.
Controlled releases
Releases are planned, reviewed and recorded.
Health checks
Services report whether they are ready and working.
Rollback
A release that misbehaves can be withdrawn to the previous version.
Infrastructure monitoring
Hosts and services are watched alongside the application.
10 · Security validation
Tested, not assumed.
Vianmax™ supports security validation practices, including vulnerability assessment and penetration testing, as part of production security assurance. Mature production environments should be tested before launch and again after significant change.
The scope of testing is agreed with each client and depends on the platform and its deployment. Findings are treated as confidential and tracked through to remediation.
- Vulnerability assessment
- Penetration testing
- Dependency scanning
- Configuration review
- API security testing
- Authentication testing
- Authorisation testing
- Infrastructure review
- Remediation tracking
11 · Business continuity
Continuity is designed, documented and rehearsed.
Business continuity is the plan for keeping an organisation’s critical services available, or restoring them, when something goes wrong. For a platform, it rests on a small number of disciplines.
- Availability planningHow available each service needs to be is agreed with the client.
- Backup strategyWhat is backed up, how often and where, set per deployment.
- Recovery proceduresWritten, tested steps rather than knowledge held by one person.
- MonitoringProblems are detected early enough to act.
- Incident responseDefined roles and steps for when something goes wrong.
- Redundancy where configuredDuplicated components where the requirement justifies them.
- Controlled recoveryRestoration in a known order, with verification.
- Operational documentationRunbooks and handover notes that another engineer can follow.
12 · Security by design
Security is engineered into the platform lifecycle.
Security is a property of how a platform is planned, built and run, not a product bolted on at the end. Every stage has a security question, and the answers carry into the next.
Figure 5 · The secure platform lifecycle
- 01PlanRequirements, risks and obligations
- 02DesignArchitecture, trust boundaries, data flows
- 03BuildReviewed, typed and tested code
- 04TestFunctional, failure and security testing
- 05DeployControlled, reversible releases
- 06MonitorLogs, metrics and alerts
- 07ImproveFindings fed back into the design
What is learned in operation returns to planning, so each cycle starts from a better baseline.
13 · Technology
A small core stack, known deeply.
We keep the core deliberately small. Fewer, well-understood technologies are easier to reason about, secure and maintain. Technology is selected according to each platform’s requirements. See our technology.
- Frontend
- React
- TypeScript
- Backend
- Python
- FastAPI
- Data
- MySQL
- Real-time
- WebSockets
- Infrastructure
- Docker
- Linux
Building a technology platform that needs engineering discipline?
Talk to Vianmax™ about architecture, security, deployment and technology requirements.