Home / Frequently Asked Questions

Frequently Asked Questions

Who are we

What is Mvine?

Mvine is a modular digital infrastructure platform that enables organisations to securely orchestrate identity, content, services, and interactions across complex ecosystems.

It provides zero-trust architecture from the ground up—combining verified identity, policy-governed access, federated content control, and digital wallet technologies in one extensible environment. Used across all industries and specifically in healthcare, property and financial services. Mvine replaces siloed portals and fragmented integrations with secure, policy-driven systems of engagement.

What does Mvine offer that traditional platforms do not?

Mvine provides identity-first, policy-enforced control over both digital assets and service access, all within a unified governance layer.

Unlike legacy DXPs, IAM tools, or collaboration suites, Mvine blends secure onboarding, entitlement orchestration, and marketplace infrastructure with role-aware content delivery and full auditability. It’s engineered for use cases where users, vendors, assets, and data all span organisational boundaries—and where assurance is non-negotiable.

Platform Overview & Architecture

What types of organisations use Mvine?

Mvine serves sectors where access control, compliance, and ecosystem complexity intersect—such as healthcare, regulated finance, and public sector services.

Whether onboarding medical staff, orchestrating vendor marketplaces, or enabling identity-based service delivery, Mvine ensures the right actor gets the right access under the right conditions—every time.

How is Mvine different from a customer portal or extranet?

Traditional portals deliver content. Mvine delivers governed digital interactions.

With Mvine, every user, asset, service, and document is scoped by role, identity, and policy—not just by login. Beyond files and dashboards, Mvine enables secure onboarding, federated credentialing, delegated access, and composable service bundles—all from a single, auditable infrastructure.

Is Mvine a product or a platform?

Mvine is a composable platform with productised modules tailored for secure service delivery.

Clients can deploy it as a full-stack system (e.g. a complete Super App) or adopt standalone modules—such as identity brokering, onboarding, content management, digital wallets, or supply chain orchestration. The architecture is containerised, API-first, and identity-governed by default.

Where is Mvine based?

Mvine is headquartered in the United Kingdom. All deployments and data handling meet UK/EU security and privacy standards.

Mvine has longstanding relationships with UK government departments, major financial institutions, and public infrastructure bodies. Deployment options include UK-hosted SaaS, on-premise containers, or hybrid integrations.

Identity & Access Management

What is Mvine’s approach to identity?

Mvine treats verified identity as the control point for all service access, policy execution, and digital entitlement.

Access to any service, content, or transaction is based on who the user is, what they’re verified to do, and what context they’re operating in—governed at runtime. This replaces role-sprawl and static ACLs with live policy resolution based on identity assertions.

Does Mvine support federation and brokering?

Yes. Mvine is an identity federation layer—integrating SAML2, OAuth2, WS-Federation, OpenID Connect, and proprietary IDPs.

It brokers identity from external providers (e.g. GOV.UK Verify, NHS Smartcard, Azure AD) and applies contextual policy within the platform. Credentials are not stored—Mvine evaluates them at runtime and maps them to internal entitlements and scopes.

How does Mvine enforce access policies?

Through a dynamic, real-time policy engine that considers role, credentials, device, region, and behavioural context.

Access isn’t binary. Policies can define conditional access (“Only if user is on VPN and verified within 30 days”) or role-triggered visibility (“Only show service X to users with verified contractor clearance in org Y”).

Can Mvine support multi-factor and biometric authentication?

Yes. Mvine supports MFA via TOTP, SMS, app-based authenticators, and integrates with biometric ID services such as iProov or Yoti.

Authentication method can vary by user risk score, asset sensitivity, or device trust. This enables asymmetric MFA policies—where one user may require biometric re-auth, another doesn’t.

Are delegated or hierarchical roles supported?

Yes. Roles can be nested, time-limited, and delegated under governance rules.

For example, a regional lead can provision sub-users, manage their access, and perform actions on their behalf—while remaining within delegated scope. Policy ensures no uncontrolled privilege propagation.

What does zero-persistence identity mean in Mvine?

Mvine performs real-time verification of identity and entitlements without storing passwords or biometric data.

It holds assertions and tokens only as long as needed to enforce policy. This reduces compliance overhead, avoids duplication, and ensures alignment with ISO27001 and GDPR norms.

Digital Wallets & Credentials

What is the Mvine Digital Wallet?

It is a secure, policy-governed container for verified credentials, entitlements, passes, and identity-linked tokens.

Users don’t just log in—they carry proof. Each wallet item can affect service access, content visibility, workflow eligibility, or contractual authority. The wallet travels with the user across modules, services, and sessions.

What types of credentials can be stored?

Passes, access clearances, qualifications, roles, licenses, biometric proof, onboarding completion flags, consent records, and more.

All items are cryptographically verifiable and can be time-bound, revocable, or nested under broader entitlements. Example: a “subcontractor” role implies access to site manuals, training modules, and team communications.

How does Mvine use the wallet to drive access?

Services interrogate wallet contents in real time—without re-authentication.

Access is granted (or denied) based on current wallet state. For instance: “Allow access to Dataset X only if wallet contains valid HMG security clearance + data usage consent + geo-fence match.”

How is wallet content issued or revoked?

Issuers (admins, verifiers, trusted systems) can assign or revoke credentials by rule or workflow.

Revocation propagates instantly across access layers. Credentials may also auto-expire or trigger renewal flows. Users can carry credentials from multiple issuers—each validated separately.

Can the wallet be embedded in other environments?

Yes. Wallet views and token checks can be embedded into portals, apps, APIs, and service flows.

No need for a separate app. Wallet interactions can occur inline within onboarding, purchasing, or access sequences—fully brandable and policy-enforced.

Is the wallet interoperable?

Yes. Mvine supports verifiable credential formats, QR/NFC interactions, and standards-based exchanges (e.g. W3C VC, OpenID, FIDO).

This ensures cross-platform compatibility, forward-compatibility with national ID systems, and flexibility across service ecosystems.

User Onboarding & Lifecycle

What is Mvine’s onboarding model?

Onboarding is an orchestrated flow of identification, verification, policy evaluation, and contextual access provisioning.

It’s not a single signup form—it’s a dynamic trust sequence tailored to who the user is, what they need, and what assurance level is required. Each step can be conditional, automated, delegated, or externally validated.

Can onboarding workflows vary by role or user type?

Yes. Mvine supports conditional, branching flows that adapt by actor type, risk posture, or trust domain. For example: Staff = SSO + attribute sync. Contractors = ID check + document upload + approval. Public users = progressive access + optional MFA. Each results in different access scope, lifecycle timer, and governance rules.

What identity sources are supported at onboarding?

Federated IDPs, biometric verifiers, manual checks, and invite-based workflows.

Mvine supports GOV.UK Verify, NHS ID, enterprise SSO, Yoti, iProov, and more. Verification happens at the edge; Mvine brokers trust and maps it to access rights.

What happens after a user is onboarded?

Lifecycle management takes over—driving role updates, access expiry, recertification, and conditional deprovisioning. For example: If a contract ends → access is revoked. If training expires → role is downgraded. If verified again → entitlements are extended. The user’s access is always aligned to their verified, active state.

Can onboarding be delegated?

Yes. Delegated onboarding is enabled under controlled governance scopes.

Team leads, regional managers, or partner admins can invite and manage users—but only within defined boundaries (e.g. geography, time, role class). Every action is logged and enforceable under policy. This supports scale without loss of control.

Content & Asset Management

What is Mvine’s content management model?

Every content object—document, video, form, dataset—is bound to policy, metadata, and identity scope.

Access is not folder-based or statically permissioned. Instead, Mvine evaluates in real time who can see, edit, publish, or share based on user role, credentials, device, jurisdiction, and context.

What types of content and assets are supported?

Structured and unstructured data: files, dashboards, rich media, HTML fragments, embedded graphs, third-party views.

Assets can originate in Mvine or be injected via APIs from CMS, DAM, or document systems. Each carries metadata, version history, and audit records.

How is access controlled at asset level?

Granular policies govern visibility, interaction, version access, and contextual presentation.

For example: show a risk report only to users in a “compliance lead” role with current GDPR certificate; let engineers view manuals but not export them unless on a corporate device; restrict outdated versions unless marked as legacy reference.

Is there support for collaboration and delegated publishing?

Yes. Users with publishing rights can create, update, or share content under policy constraints.

Delegated roles (e.g. editors, trainers, validators) can upload or modify content with approval gates, tagging rules, expiry conditions, and rollback safeguards.

Is every interaction logged?

Yes. View, download, edit, comment, share—all tracked with timestamp, user ID, and device metadata.

This supports forensic reconstruction, compliance review, and defensible governance. Full audit trails can be exported or fed into SIEM or compliance systems.

Marketplace & Ecosystem Models

What marketplace models does Mvine support?

Mvine enables structured ecosystems: B2B, B2C, and BnBnCn—with layered roles, scoped offers, and entitlements-as-access.

Each actor (supplier, broker, consumer) is governed by identity, credentials, and policy. Offers appear or remain hidden based on verified role, clearance, region, or time window.

What is BnBnCn and how is it enabled?

It stands for Business-n-Business-n-Consumer—where layered businesses repackage or resell services under joint governance.

Mvine supports scoped branding, service wrapping, entitlement gating, and delegated administration at each level. Example: a government programme is wrapped by a local authority, brokered by a charity, and consumed by verified citizens.

Can participants publish or manage offers?

Yes, with rule-based delegation.

Each vendor, broker, or channel partner may configure offers within policy constraints. Controls include eligibility criteria, credential requirements, visibility limits, branded storefront overlays, and conditional pricing. Admins define moderation gates and override conditions centrally.

How are transactions tracked and attributed?

All offer views, acceptances, and usage are logged per actor, entitlement, and referrer.

Mvine supports commission rules, quota logic, per-actor analytics, and cross-ecosystem usage tracking. Attribution is built-in—not retrofitted.

Can services or content bundles be dynamic?

Yes. What a user sees in the ecosystem depends on wallet state, policy, identity source, and context.

For example: a user with verified NHS ID sees clinical support bundles; a local authority manager sees supplier dashboards; a verified subcontractor sees offer packs only during a contract period. This is not a static catalogue—it’s a personalised, governed service surface.

Deployment & Integration

How is Mvine deployed?

Mvine supports cloud-hosted, on-premise, hybrid, and air-gapped deployment models.

All modules are containerised and orchestrated via Kubernetes, enabling isolation, resilience, and flexibility. Clients retain full control over data residency, network policies, and hosting environments—supporting regulated and sovereign requirements.

Can Mvine integrate with existing IT systems?

Yes. Mvine provides API connectors, webhooks, and SDKs for ERP, CRM, CMS, HRIS, IAM, SIEM, and bespoke applications.

Integrations are policy-aware—meaning access is governed not just by API tokens but by identity and entitlement of the calling party. Events can flow in either direction: provisioning, verification, content injection, or entitlement sync.

Does Mvine support white-labelling and embedding?

Yes. The entire platform UI and module surfaces can be branded, themed, and embedded into external portals, mobile apps, or kiosks.

You can present Mvine modules as native parts of your user experience while retaining centralised governance, policy enforcement, and audit control.

Can Mvine function as a headless backend?

Yes. Mvine’s core logic—identity orchestration, wallet evaluation, content gating, entitlement resolution—can be exposed via APIs for headless integration.

This enables use cases like app-native onboarding with backend identity federation; embedding policy-bound service access into existing mobile frameworks; and driving content visibility via third-party decision engines.

What if I want to deploy only one module?

Mvine is composable. You can deploy a single capability (e.g. wallet, onboarding, marketplace) and integrate it into your existing stack.

Modules operate independently with common identity, policy, and audit infrastructure. Over time, you can extend deployment to adjacent capabilities without starting over.

Compliance & Security

What compliance frameworks does Mvine align with?

Mvine is aligned with ISO/IEC 27001, GDPR, Cyber Essentials+, and UK public sector assurance baselines.

The platform has been deployed across all industries and specifically in healthcare, property and financial services, with third-party security validation and architecture-level risk assessments.

How does Mvine implement zero-trust security?

Every transaction, access attempt, and data exposure is governed by real-time identity, context, and policy—not network location or user status.

There is no implicit trust for internal users or whitelisted IPs. All actions are logged, scoped, and revalidated at the moment of interaction.

How is data protected within Mvine?

All data is encrypted in transit and at rest. PII is minimised, tokenised, or replaced by verifiable assertions wherever possible.

Mvine uses TLS 1.2+ with forward secrecy, AES encryption at storage layer, strict RBAC at data access points, and tamper-evident logs. Sensitive fields can be selectively encrypted or redacted per role.

Does Mvine store passwords, biometrics, or raw credentials?

No. Mvine does not persist passwords, biometric images, or raw identity tokens.

It performs runtime verification via external identity providers or brokers, and stores only assertions and time-limited tokens. This reduces breach surface and simplifies compliance.

Is there full auditing capability?

Yes. Every action—login, access, approval, publication, revocation—is logged with user ID, device, timestamp, and context.

Audit logs are immutable, exportable, and can be routed to SIEM tools or compliance dashboards. This supports internal governance, external regulation, and forensic reconstruction.

Billing, Licensing & Commercials

How is Mvine licensed?

Mvine is licensed per-module, per-environment, with optional user-based tiers where applicable.

You can license individual components (e.g. identity brokering, wallet, onboarding) or the full platform. Licensing supports SaaS, private cloud, or on-prem deployments with clear support tiers.

Is there a per-user cost?

Only for modules where end-user volume materially impacts system load or entitlement provisioning.

Many modules are licensed per-function or per-instance, enabling ecosystem-scale deployment without runaway per-user costs. Public-facing or partner-facing use cases are priced to allow wide participation under governance.

Are white-labelling and OEM scenarios supported?

Yes. Mvine offers branding, theming, and multi-tenancy controls as part of its commercial model.

This includes managed service operators, partner distribution models, and embedded platform use. OEM arrangements can include volume pricing and pre-integrated branding.

Can Mvine be trialled or piloted before commitment?

Yes. Pilots and phased deployments are supported under paid proof-of-concept models.

These can include integration sprints, isolated modules, or live user onboarding under controlled conditions—allowing commercial and operational testing without full rollout.

What support and SLAs are included?

Support tiers include standard, enhanced, and mission-critical—with SLAs covering response, uptime, and incident handling.

24/7 options are available. Mvine also offers integration support, security validation, training, and onboarding assistance as part of structured engagement packages.

Categories
  • Who are we
  • Platform Overview & Architecture
  • Identity & Access Management
  • Digital Wallets & Credentials
  • User Onboarding & Lifecycle
  • Content & Asset Management
  • Marketplace & Ecosystem Models
  • Deployment & Integration
  • Compliance & Security
  • Billing, Licensing & Commercials