About this demonstration
Every scenario is a deterministic, synthetic demonstration set in a fictional universe (Aster Market, Lumen Digital, PSP-A/PSP-B). It shows a designed decision discipline — not a live deployment, a customer result or a production claim. Nothing is submitted, stored or tracked; the full boundaries sit under ‘What this does not prove’ at the end of each story.
One merchant. Four moments where the decision is tested.
Enter the same fictional case through the pressure your role owns. See what may move, what must stop, who acts next and what the resulting record can support.
- 01
CaptureFix the signal, source and purpose before interpreting them.
- 02
GovernApply the relevant scope, policy and mandatory boundary.
- 03
DecideChoose a posture without hiding held or unresolved work.
- 04
ChallengeExpose review, exceptions and the next accountable owner.
- 05
ProveAssemble an inspectable artifact with its limits still visible.
Pick a posture — the lanes answer.
- Synthetic DEMO
- 2–4 minutes
- No sign-up
- Nothing leaves this browser
Keep commerce moving. Keep control intact. Keep decisions defensible.
TrustStack ORION is designed for marketplaces, high-risk e-commerce, merchants and PSPs whose commercial continuity depends on decisions that Payments, Compliance, Engineering and partners can all understand. Explore the reference platform—or pressure-test the idea in one connected synthetic scenario universe.
Start with your buying question
Each route is self-contained, keyboard-operable and printable. No sign-up wall; no data collection.
03:17 — The Continuity Room
Choose an operating posture, meet a mandatory-control boundary, and see what remains unresolved.
COO · Head of Payments · Operations Run this scenario 02 Govern one merchant across five teamsOne Merchant — Five Realities
Keep merchant facts fixed while Operations, Payments, Compliance, Engineering and Procurement make their responsibilities explicit.
COO · CRO/MLRO · CTO/CISO · Product Run this scenario 03 Test whether the evidence holdsProof Lab — Try to Break the Decision
Remove provenance, collide maker and checker, expire the grant, and see exactly where confidence stops.
MLRO · Audit · CISO · PSP diligence Run this scenario 04 Map a bounded 90-day pilotBuild Your Control Map
Start with one decision journey, select systems and an operating posture, then generate a scoped pilot blueprint.
Executive sponsor · Product · Procurement · CTO Run this scenarioSynthetic scenario · illustrative product experience · Nothing is submitted. This experience uses no cookies, analytics or browser storage.
Outcomes we engineer for
Targets agreed per segment in the pilot Statement of Work — then measured weekly, in the open.
Illustrative hypotheses only. Baselines, measures and acceptance gates must be agreed for the scoped evaluation; no customer outcome or coverage is implied.
Drag the line. Test the hypothesis.
A brochure-derived DEMO model for one hypothetical high-risk merchant and one month of unchanged traffic. Red is an illustrative current-state input; teal is a candidate target for evaluation — not observed or expected TrustStack performance.
High-risk merchants don't fail on demand. They fail on infrastructure.
Processor exits, chargeback programs, VAT exposure, KYC debt, licensing scrutiny — each one alone can stop a business that customers love. Generic PSP stacks weren't built for this.
Payments
- Processor exits, reserves and sudden holds
- FIAT + crypto complexity and routing
- High decline rates and MCC friction
- Payout bottlenecks and settlement risk
Fraud & disputes
- Chargebacks that threaten processing continuity
- Refund abuse, ATO, triangulation
- Manual-review cost and false declines
- Friendly fraud and policy exploitation
Compliance
- VAT/GST across jurisdictions
- KYC, KYB and AML obligations
- Reporting, record-keeping, audits
- Licensing exposure in gambling, crypto and adult verticals
Governance
- Sanctions and geo controls, product gating
- Risk appetite and policy enforcement
- Incident workflows and evidence packs
- PSP questionnaires and partner due diligence
One decision layer. Controls that compose.
Designed to connect agreed product, processor and policy signals to governed decisions and inspectable evidence—within a scope validated during diligence.
Where the producing workflow records them, decision context and evidence references can support disputes, audits and partner diligence; missing fields remain explicit.
A decision trail should explain more than a log file.
A Decision Record is designed to preserve the fields actually produced for an approve, step-up, review or block: outcome, applicable rules and versions, recorded inputs, rationale, correlation and governed review. Scoped exports can assemble available evidence; absent or inapplicable fields are never invented.
Same synthetic transaction shape, different DEMO signals — inspect how an illustrative decision fixture changes.
See how evidence worksThe Compliance Console, at a glance
A stylized view of an entitlement-driven module rail, a configurable review queue and a Decision Record panel. Product UI is shown in English; surface availability and workflow behavior depend on the reviewed module caveats.
Illustrative preview only. Validate the current surface, role, entitlement, configuration and data path in a scoped walkthrough.
Start with one decision journey. Compose the domains it needs.
The reviewed registry contains six core, four add-on and four platform domains, all currently marked ui. Entitlements, integrations and production scope are confirmed per tenant; registry presence is not general availability.
GATE provides an observed starting surface for hosted KYC and party context. It is designed to support scoped onboarding and identity decisions with explicit review and evidence boundaries where configured.
Current surface: hosted KYC and party reads; review is feature-flagged; UBO capture is absent in the reviewed state.
Learn morePULSE exposes a Decision Explorer and part of the rationale behind a decision. Its designed-to direction is rules-first, model-optional decisioning whose recorded inputs, rule references and limitations remain visible.
Current surface: Decision Explorer with partial rationale; the ML indicator is a stub, not an active-model claim.
Learn moreSWITCH currently shows parts of routing configuration and payment-path history. It is designed to support bounded, eligibility-aware routing decisions once provider connections, data contracts and operating controls are validated.
Current surface: partial routing-configuration and payment path-trail reads; no live provider or automatic failover is inferred.
Learn moreLEDGER's strongest observed surface is its books-oriented UI. The designed-to scope connects postings, reconciliation and dated tax snapshots, while keeping static tax assumptions and reporting purpose explicit.
Current surface: books are the strongest observed area; tax rates are static and must be shown with their rate-basis date.
Learn moreSENTINEL exposes screening and policy UI/read surfaces. It is designed to make policy scope, version, disposition and review visible without presenting a demonstration list as live sanctions or adverse-media coverage.
Current surface: screening and policy reads use a DEMO screening list; list coverage and live feeds are not established.
Learn morePRISM provides observed dashboard and generate-now scorecard surfaces. It is designed to compare agreed measures and assemble purpose-bounded reporting from data that is actually available and attributable.
Current surface: dashboards and generate-now scorecards; scheduled reporting, contractual service-level monitoring and authority-accepted output are not established.
Learn moreThree commercial hypotheses to evaluate
Test continuity
- Measure eligible routing against an agreed baseline
- Observe false-decline trade-offs
- Validate available APM and corridor scope
Test loss controls
- Measure disputes and fraud signals
- Exercise refund-abuse controls
- Evaluate ATO and triangulation patterns
Test operating effort
- Measure manual-review demand
- Assess evidence-pack completeness
- Time agreed audit and reporting tasks
What would TrustStack move for you?
Drag the sliders to your numbers. The arithmetic is the brochure's: approval uplift captures sales, dispute reduction cuts losses. Indicative and segment-dependent — the 90-day pilot replaces this model with your measured data.
Model, not a quote: dispute savings assume the <0.5% target; actuals depend on vertical, traffic mix and existing controls. KPI targets are agreed per segment in the pilot Statement of Work.
Two ways to run it
White-label SaaS model
- Integrate the agreed APIs and operate configured dashboards and queues
- Configure validated rules, thresholds, policy packs and routing preferences
- Scope reporting for finance, compliance and operations
- Define service objectives, support and monitoring in diligence and contract; no public SLA is implied
Managed-service model
- Monitoring, tuning and review can be scoped with named responsibilities
- Compliance advisory may cover agreed VAT, AML, content-governance and dispute questions
- Evaluation cadence and purpose-bounded documentation are agreed per engagement
- Any risk-transfer or coverage concept requires separate underwriting and contract and is not represented as currently offered
Your vertical. Your pressure points. A testable starting scope.
Choose a vertical to explore indicative pressure points, candidate control questions and potentially relevant ORION domains. This is a scoping aid, not an active policy pack or a statement of supported coverage.
Built by compliance engineers.
TrustStack ORION is built and operated by E-KMC.EU P.S.A., a Gdańsk-based compliance engineering company led by Marek Kamiński, PhD in Law. The regulatory practice came first; the platform is how that practice scales.
- A compliance practice first: policies, audits and regulator-facing work for high-risk commerce precede the product.
- Engineering under the same roof: the module registry, evidence model and controls are designed and built by one team.
- Diligence over decks: the diligence pack — programme of operations, security baseline, isolation evidence — is available under NDA.
Trust starts with inspectable control boundaries.
The target design combines tenant isolation, row-level controls, append-oriented audit patterns and hash-based integrity checks. Distinct review is applied where configured; evidence-pack completeness and reproducibility are tested within the agreed scope.
Security & auditabilityTest one decision journey against an agreed baseline.
A scoped 90-day evaluation can use synthetic, shadow/read-only, bounded-exercise or carefully approved production posture. Diligence and contract define the hypothesis, controls, evidence gate and stop conditions before any live intervention.