Security Disclosures
This page documents what Elysium Nexus does not do, the boundaries of its analytical outputs, and limitations that integrators and compliance reviewers should be aware of.
All statements verified against source code at commit 4b572c2.
Advisory-Only Outputs
Every analytical output produced by the platform is advisory. No component makes autonomous decisions. All financial, compliance, and customer-facing actions require explicit human approval through the workflow engine.
The platform does not:
- Block, hold, or reverse transactions
- Approve or deny credit applications
- File regulatory reports (SAR, CTR, EDD) autonomously
- Freeze accounts or suspend customers
- Send communications to end customers without human review
Cash runway warnings and late payment reminders are auto-sent notifications (no approval gate), but they do not trigger any financial action.
Scoring Methods
The platform uses three categories of analytical methods. Each output includes a scoringMethod field so consumers know the provenance.
Deterministic (Heuristic)
Rule-based calculations with fixed, auditable thresholds. Given the same input, they always produce the same output. This is the default scoring method for all services.
Components using deterministic scoring include: business health scoring, fraud signal detection, next best action recommendations, seasonal adjustments, SME health calculations, and peer benchmarking.
Statistical
Mathematical models with documented formulas. Deterministic given the same input and model parameters. Used for risk scoring, credit state modelling, cashflow trend extrapolation, and confidence interval estimation.
ML (Optional)
Machine learning models that may produce different outputs as models are retrained. Always optional; always falls back to heuristic if unavailable. ML scoring is activated only when explicitly configured and when model dependencies are available.
Training data disclosure: All ML models are currently trained on synthetic data generated from heuristic rules. Model accuracy on real-world production data has not been independently validated.
Tenant Boundary Guarantees
What Is Guaranteed
- Application-layer isolation: Every database query is scoped to the authenticated tenant, enforced at compile time.
- Database-layer isolation: PostgreSQL Row-Level Security policies provide a second layer of tenant filtering.
- Fail-closed default: If the tenant context is not set, zero rows are returned.
- Input validation: Tenant identifiers are validated before use in queries.
- Header trust boundary: Tenant context is only accepted from authenticated internal service calls, never from external client headers.
What Is Not Guaranteed
- Cross-region replication: The platform is deployed in a single region. Cross-region failover is not implemented.
- Hardware-level isolation: Multiple tenants share database infrastructure. Isolation is enforced at the software layer, not via dedicated infrastructure per tenant.
Pilot Considerations
For pilot deployments, integrators should be aware of:
- Business health scoring requires sufficient transaction history for meaningful trend detection
- Peer benchmarking requires a minimum peer group size for statistical significance
- External compliance integrations (sanctions, PEP) require separate provider provisioning
- Regulatory report templates are generic and may require jurisdiction-specific customization
What the Platform Explicitly Does Not Do
- No autonomous financial decisions. Every credit, compliance, and customer-facing action requires human approval.
- No transaction blocking. The platform cannot intercept, hold, delay, or reverse transactions on connected systems.
- No direct regulatory filing. Regulatory reports are prepared as templates; filing is a manual process.
- No customer-facing communications. The platform does not send emails, SMS, or notifications to end customers.
- No PII in AI processing. Customer data is sanitized before being sent to LLM providers.
- No training on customer data. ML models are trained on synthetic data. Customer data is used for inference only.
All disclosures verified against source code at commit 4b572c2.