Modirum

Service Overview

First the structure. 3DS is not one company's product but a chain. A merchant or acquirer submits a transaction to a 3DS Server, the 3DS Server passes it to the scheme Directory Server, the Directory locates the issuer ACS, the ACS runs the challenge, and the result travels back. Each link has a different supplier. A merchant only touches the 3DS Server, sometimes only indirectly, while the Directory belongs to the scheme and the ACS belongs to the issuer. A meaningful share of the 3DS experience therefore sits outside merchant control: the challenge page, whether frictionless passes, and what error returns on failure are issuer and scheme decisions.

Modirum is an engineering contractor on that chain rather than a tool vendor for merchants. It is a group, Modirum Group, whose slogan is building a better future through technology, organised into 5 units: Modirum Platforms including Modirum and Gespi, Modirum International, Modirum Payments, Modirum Consulting and Modirum Ventures. Group-level published figures are 25+ years of experience, 1000+ professionals, 50 countries covered, 1.3M+ security tasks delivered and 15 governments served. Its business spans fintech and broadcasting among other areas, with an emphasis on securing every step.

Those numbers are vendor statements at group level and need to be read on two levels. First, group figures are not single-product capability: 1000+ professionals spread across 5 units does not mean a 3DS team of that size. Second, 1.3M+ security tasks and 15 governments demonstrate accumulated engineering and security delivery experience, and do not imply that a specific 3DS metric outperforms peers. The figures are useful for judging whether the company can genuinely deliver, not for judging how much faster its 3DS is.

The group structure and the security task and government client language show that Modirum is closer to an engineering contractor building 3DS and PKI security infrastructure for issuers, acquirers and governments, with project-based and customised delivery, than to a self-service SaaS product for merchants. That defines its position. For ordinary merchants it is usually not an option, because you cannot reach it and do not need it; it is a candidate for institutions building their own ACS or 3DS stack, or with local compliance and sovereignty requirements.

The selection criteria are therefore not feature-list comparisons but two questions: whether you can absorb a project-based delivery, and whether you need local ownership and control. Feature comparison means little under project delivery, where budget, schedule, acceptance criteria and run responsibilities decide the outcome.

Key Strengths

• Engineering delivery rather than off-the-shelf subscription: project delivery allows custom requirements, interfaces, reporting and compliance evidence to match the institution's own processes. For regulated institutions this is often more useful than a few extra standard features.
• Experience across financial and public sectors: delivery for 15 governments implies familiarity with demanding acceptance, audit and data residency requirements, which merchant-facing payment vendors rarely accumulate.
• 3DS and PKI capability from the same source: authentication rests on key management, signing and certificate lifecycle, which overlaps heavily with ACS implementation. One supplier for both reduces the blame-shifting that comes with vendor boundaries.
• Built for on-premise and sovereignty requirements: institutions with data residency, localisation or public procurement obligations usually cannot accept a multi-tenant cloud service, and project delivery is a precondition there rather than a bonus.
• Resources can be combined inside the group: Platforms, International, Payments, Consulting and Ventures allow advisory, implementation and operations to be packaged, instead of the institution coordinating several vendors itself.
• Reusable across industries: running fintech and broadcasting in parallel means the security and authentication components have been tested under different regulatory and operational conditions, which usually forces a round of interface abstraction.

Product Ecosystem

3-D Secure and Issuer-Side Authentication

3DS and authentication work sits in the Modirum Platforms unit including Modirum and Gespi. Delivery centres on building a proprietary ACS, integrating a 3DS stack and customising issuer-side authentication flows rather than on a standard subscription. The exact component list and scheme certification status follow the official documentation and your contract.

PKI and Security Infrastructure

The group figure of 1.3M+ security tasks points to engineering delivery around keys, certificates and signing. In 3DS terms that capability supports challenge result signing, certificate rotation and the evidence trail an audit requires, which is the underlying condition for ACS acceptance.

Group Structure and Delivery Model

Modirum Platforms, Modirum International, Modirum Payments, Modirum Consulting and Modirum Ventures handle platform development, international business, payments business, consulting and investment functions. For a buyer this means one contract may combine software licensing, implementation services and advisory work, so acceptance terms need to be written up front.

Broadcasting and Other Industry Solutions

The group spans fintech and broadcasting among other directions. The point of multiple industries is not diversification as such but that the security components must work under different regulatory and operational environments, which pushes interfaces and deployment models toward configurability.

Limitations

• Effectively unavailable to merchants: its customers are issuers, acquirers and government institutions. Merchant 3DS normally arrives through the acquirer or gateway, and going around that path to an engineering contractor is neither economical nor a realistic purchasing route.
• Project delivery leaves little room for trial and error: SaaS can be piloted and expanded, while project delivery locks scope, budget and schedule at signature. Institutions with vague requirements tend to iterate during implementation and pay for it.
• Part of the 3DS experience is outside your control: even with a self-built ACS and 3DS Server, the challenge page users see, the frictionless pass rate and the failure semantics remain bounded by scheme directory rules and regulatory exemptions.
• Frictionless ratios follow risk models and exemptions: engineering can implement rules more precisely and wire in finer signals, but it cannot change the exemption framework or promise a specific ratio.
• 3DS does not cover every fraud type: post-authorisation fraud, friendly fraud, first-time card binding after account takeover and parts of APP scams sit outside the authentication layer and still need independent monitoring and dispute handling.
• Compliance responsibility does not transfer: PCI DSS scope, SCA evidence and local regulatory reporting stay with the merchant and acquirer. The vendor delivers auditable systems and evidence, not an audit conclusion.
• Integration and scheme certification take months: 3DS launch requires scheme certification, and on-premise adds environment build, version upgrades and operations handover, with the full cycle often measured in quarters.
• Cost scales with volume across 2 separate budgets: project delivery splits capital build from ongoing run and upgrade costs, and volume growth adds capacity cost, so all 3 parts belong in the model.

Use Cases

• Issuers building or replacing an ACS (★★★★☆): when on-premise deployment, custom flows and local ownership are required, project delivery is a reasonable path, provided you can absorb implementation and operations.
• Acquirers building their own 3DS stack (★★★★☆): institutions that do not want 3DS capability tied to a single SaaS provider long term can internalise it through a project.
• Institutions with local compliance and data residency obligations (★★★★★): where data must stay local, audits are strict and procurement runs through public tender, project delivery and on-premise are close to the only option.
• Public sector and government procurement projects (★★★★☆): the group states service to 15 governments, indicating familiarity with public acceptance and compliance processes, though qualifications must be confirmed project by project.
• Cross-border acquirers covering several markets (★★★☆☆): differing market rules need configurable authentication flows, but each market must be validated separately rather than assumed to be covered by one delivery.
• Mainland China operations (☆☆☆☆☆): domestic card 3DS runs through domestic acquirers and the domestic scheme and overseas vendors are not part of that path. Cross-border and outbound business on overseas acquiring can use the overseas path after confirming acquirer and scheme admission for the 3DS Server.
• Worst fit: small merchants and standalone stores (★☆☆☆☆): they cannot reach this delivery model, do not need a proprietary ACS, and acquirer-provided 3DS costs far less.

Pricing

Cost drivers include SaaS versus on-premise, the number of markets and schemes covered, authentication flow complexity, the volume of data feeds needed for a frictionless policy, project scope and acceptance criteria, and who carries run and upgrade responsibility afterwards. No price list is published, so concrete figures belong in a contract, and group-scale numbers should not be used to infer pricing.

The table reflects the currently published group and business structure on the Modirum website. No standard rate card is published; actual quotes, delivery scope and supported countries are governed by your contract.

FAQ

• I run a cross-border store. Can I use Modirum?
  Usually not. Its delivery targets issuers, acquirers and government institutions, and merchant 3DS arrives through the acquirer or gateway. Approaching it skips the link you actually need to integrate.

• Is its 3DS a standard product or a custom project?
  Mostly project based and customised. Components, interfaces and delivery scope are agreed in the contract, so purchasing resembles a systems integration project rather than a subscription.

• Do those group numbers mean the product is stronger?
  Not directly. 25+ years, 1000+ professionals, 1.3M+ security tasks and 15 governments are vendor statements at group level. They evidence delivery experience but not superiority on any single 3DS metric, which still needs requirement validation and reference projects.

• What does building your own ACS require?
  At minimum scheme certification time and cost, integration resources with the directory, key and certificate lifecycle management, and post-launch operations plus compliance evidence. Missing any one of these extends the project.

• Is it suitable for mainland China institutions?
  Domestic card 3DS runs through domestic acquirers and the domestic scheme and overseas vendors are not part of it. If the institution has overseas acquiring or issuing, a project evaluation is possible, subject to local scheme admission and certification requirements.

Source: original 16IDC content. Product capabilities, supported countries and fee definitions follow the official documentation on modirum.com and your contract.