Ludera.io: Compliance Orchestration for Crypto Exchanges

Ludera is the compliance orchestration platform from Ludo Labs AG. Pharos Production engineered the application that connects asset research and screening to the people responsible for reviewing a listing, following up on a finding or reassessing an existing asset. The central object is a case with its evidence, assigned work, review history and recorded outcome. The platform brings together a configurable flow builder, forms, service integrations, a risk engine and an Action Center. A reviewer can follow the path from an applicant's documents to provider results and the final decision, rather than reconstructing that path across separate dashboards. Our MiCA compliance software practice covers the wider engineering work around these controls.

An exchange can already have white paper analysis, sanctions screening, wallet intelligence and contract security tools. Their outputs still arrive in different formats, at different times and with different owners. Someone has to correlate the findings, determine what needs review and preserve the explanation behind the decision.

We built Ludera around that handoff. Automated checks collect evidence and populate the workflow. Assigned reviewers validate it, request clarification or escalate the case. The same operating model continues after listing, when stakeholder information, asset behavior or the exchange's own policies change.

Intake collects the asset's identity, chain and contract address alongside its white paper and stakeholder information. Documents and declared information become inputs to the case, rather than attachments detached from the assessment. AI-assisted extraction can suggest information from the white paper, while the applicant or reviewer can correct the proposed values. Manual contract entry also supports address enrichment, so the workflow does not depend on a white paper containing an on-chain address. User-entered values take precedence over enrichment suggestions. The distinction matters when an automatically discovered address is incomplete or the applicant supplies a correction. For the document requirements themselves, see our MiCA white paper requirements guide.

The workflow dispatches independent checks concurrently and brings their normalized results together before the relevant review stage. Stakeholder screening can fan out across the people declared in the application; wallet and contract checks can operate on the addresses associated with the asset. Each execution retains its status and evidence.

A convergence step waits for the required upstream work before combining results. This separates collecting evidence from deciding what it means. A failed provider call remains a failed check with a reason to inspect; it does not become an empty result that looks like a clean screening.

The listing workflow supports parallel regulatory and compliance review tracks. First-stage reviewers inspect the evidence, followed by senior review from the responsible legal and AML functions. Supervisory review and an executive listing decision remain explicit steps with named responsibility.

1. Create the case from the intake submission.
2. Collect and normalize the required automated checks.
3. Validate regulatory classification and compliance risk factors.
4. Escalate to senior reviewers with the earlier evidence in view.
5. Calculate the configured risk assessment.
6. Complete the supervisory reviews.
7. Record the authorized listing decision and its rationale.

This is an implemented workflow pattern that an exchange can configure around its own review structure. The software supports the review; token classification remains a legal determination. Our ART, EMT and other token classification guide explains the distinctions, including the separate MiCA and MiFID II boundary.

Ludera's service layer connects document analysis, AML and sanctions screening, adverse media, wallet KYT, contract security and jurisdictional checks. Market data and holder information add context to the asset assessment. The available coverage depends on the providers and services enabled for the exchange.

Adapters normalize external responses for the workflow while preserving the underlying result for inspection. A risk band, a numeric score and an unavailable result have different meanings. The application must retain those differences when it presents a summary, populates a form or compares a later check.

A sanctions or adverse-media result belongs to a particular person or organization. A wallet result belongs to a chain and address. Ludera carries that subject context into the case so a reviewer can distinguish a stakeholder match from an asset-level signal and open the relevant report. Review forms can carry the prior-stage submission, provider summaries and report links together. Reviewers retain the ability to change a proposed finding and add their own rationale. Our MiCA KYC and AML guide discusses how these controls fit into the wider onboarding stack.

The risk engine evaluates a configured factor profile using the exchange's weights and thresholds. The score is accompanied by the factors and mitigation information that produced it, giving reviewers something they can examine and challenge.

Scoring follows the evidence and review stages. It supports the authorized decision instead of silently approving a listing. Keeping policy parameters separate from workflow execution also lets a team adjust its risk model without replacing the surrounding case-management process.

We integrated LLM-based analysis as a bounded service inside the workflow. It reads the white paper and, where configured, a digest of the case's collected information. Its output proposes factor assessments with a rationale and supporting citations.

Those suggestions populate review fields that a person can inspect and edit.

The model call does not control the listing workflow or authorize an outcome. Explicit workflow rules route the case, and authorized reviewers decide. This is a practical example of the distinction in our guide to AI agents versus LLM calls: document reasoning can be useful inside a governed process without handing the process to an autonomous agent.

A white paper's silence about a subject is not proof of an adverse finding. The analysis contract therefore distinguishes yes, no and unknown. An unknown answer leaves the corresponding decision field for review rather than inventing an answer to fill the form.

The prototype checks included documents with explicit disclosures and a synthetic document that omitted team and funding information. That omission had to remain unknown. The implementation also normalizes citations and keeps the proposed rationale visible, so the reviewer can judge both the suggestion and its basis.

The AI service is advisory.

If a document cannot be read, a provider is unavailable or a response cannot be parsed, the analysis returns an unavailable explanation and unknown factors. It does not fabricate a favorable assessment or stop the entire case from reaching a human reviewer.

This fallback applies to the advisory analysis, not to every required compliance check. Required evidence and approval gates remain part of the exchange's configured workflow. The distinction preserves a usable manual review path without weakening the controls that decide whether the case may progress.

Ongoing checks need a stable record of what they are checking. Ludera retains the asset's chain and contract identity, stakeholder subjects and risk profile beyond the original onboarding run. A later cycle can use that registry instead of rebuilding its subjects from a new form submission.

The successful checks from enrollment establish the comparison baseline where the service supports a comparison rule. Malformed or unsupported results do not become a valid baseline. This gives the next run a meaningful reference and makes the absence of comparable evidence visible.

The monitoring scheduler supports company-level defaults and asset-specific overrides for each supported monitoring flow. Standard and enhanced supervision can use different configured intervals. An explicit local disable remains disabled instead of silently inheriting an enabled company default.

The worker claims each due execution slot before starting a cycle, so competing application instances do not launch the same scheduled work twice. It also reconciles completed cycles before scheduling more work. The execution history therefore remains usable even when a run completes without an operator watching the page.

A stakeholder recheck may update only part of an asset's risk profile. We designed the risk-delta calculation to merge those new observations into the stored profile before calculating the new score. Factors outside that cycle remain intact, including their mitigation state. A cycle that examines no subjects cannot demonstrate that risk fell. It returns an explanation that a comparison cannot be made. This prevents an empty execution from looking like an improvement and gives reviewers a reason to investigate the missing coverage.

Threshold rules can evaluate an absolute reading or a change over a configured time window. The first observation establishes a baseline; subsequent evaluations detect a crossing. A value that remains beyond the same threshold is not treated as a new crossing on every evaluation.

Cooldown and rearming rules control repeat work. Missing readings, an unavailable historical reference or a zero baseline for a percentage calculation remain explicit non-applicable conditions. Crossing a threshold can launch the configured review flow; it does not itself approve a listing restriction or delisting.

The Action Center brings assigned work into a common queue. Departments and individual reviewers can see the case, its priority, the work awaiting them and the supporting context. Notes, reassignment and completed actions stay connected to the item instead of being scattered through separate conversations.

Access controls distinguish who can view a case, manage the workflow or take a particular action. The interface and server-side checks both enforce these boundaries. A reviewer can follow the earlier review history before adding a decision of their own.

We modeled an asset's listing state, supervision level and monitoring operation separately. Enhanced supervision does not mean the asset has been delisted. Pausing a monitoring process does not change the exchange's listing decision. Keeping these concepts independent makes the state of the asset easier to interpret.

The decision workflow supports escalation into Special Treatment, a remediation review that can return an asset to ordinary listing, and a delisting review. Authorized human decisions and completed case stages govern these transitions. A completed delisting also stops the asset's monitoring operation.

Listing-status changes and their audit events are written together in a database transaction. The recorded event retains the reason for the transition. The application also guards against conflicting open listing cases and refuses further listing transitions after an asset has been delisted.

This turns the outcome into a history that can be reconstructed: which evidence was reviewed, who owned the work and why the status changed. For the separate challenge of detecting trading manipulation, read our crypto market-abuse surveillance guide. Ludera's case workflow provides the review and follow-up layer around findings.

The visual flow builder connects triggers, automated service checks, forms, conditional paths and human approval stages. The forms builder controls the evidence and information each stage collects. Published workflow versions provide a defined process for a case to execute.

We separated the execution mechanisms from company-specific policy and configuration. A tenant can use its own review chain, risk parameters and enabled services. Stable form-field identities allow labels and help text to change without breaking the mappings that carry evidence between review stages.

The service framework supports live integrations and deterministic sandbox responses. Sandbox operation allows a team to exercise the workflow, its forms and escalation paths without treating a simulated provider answer as a real screening result. Tenant configuration includes the related forms, department assignments and flow references. Cloning a workflow requires those references to resolve inside the destination tenant. The resulting setup can reproduce the process for testing while keeping its operating context separate from another exchange's cases.

The application uses TypeScript across a React interface and a Node.js/Express backend. PostgreSQL stores the cases, workflow executions and policy configuration through Drizzle ORM. React Flow provides the visual graph-editing surface.

Service requests and their results are persisted separately from the review interface. An external check can continue asynchronously, while the interface shows whether the work is pending, completed or failed. That execution state is part of the case context, rather than a temporary browser notification.

A common file-storage interface supports local filesystem storage and an AWS S3 backend. The application refers to logical document keys, so moving storage does not require changing the review steps that consume the documents. White papers, supporting files and generated report data remain connected to the relevant case or execution. Permission checks control access through the application. This keeps evidence retrieval aligned with the same operational boundaries as the work itself.

The implementation work included focused checks for risk-profile merging, absent subjects, baseline construction, schedule overrides and threshold rearming. These are the boundaries where a superficially successful run could otherwise produce the wrong operational conclusion.

For example, a disabled asset-specific schedule must not fall back to the company schedule. A recheck must not clear factors it did not examine. A repeated threshold breach must not keep opening identical work. Those rules are explicit parts of the implementation, supported by dedicated test cases.

Ludera brings asset intake and provider checks into the same operating process as risk assessment, human review and recurring oversight. The deliverable is a configurable application in which an operator can trace a case from its submitted evidence to its authorized outcome and subsequent asset review. Each exchange can configure its enabled services, review structure and operating policy. The workflow keeps the evidence, assigned work and decision history together as that configuration evolves.

The Ludera product site presents its current access program, including Priority Access for qualifying Tier 1 crypto exchanges and a waitlist for other organizations. The platform supports compliance teams' work; the exchange's authorized reviewers and legal advisers retain their decisions and responsibilities.

For a comparable build, our compliance and RegTech engineering team can define the required integrations, review gates and evidence model. Our MiCA compliance checklist helps frame the controls, while the MiCA compliance cost guide explains the scope variables behind an estimate.