Normexa

HOW WE WORK

From opportunity to operations.

The complete delivery lifecycle, the regulated models it can run under, and who is responsible for what at each stage.

01 / OUR PROCESS

COMPLETE LIFECYCLE · GATES · LOOPS

Two decisions shape the delivery route.

Qualify and Regulatory Feasibility are entry and decision stages; feasibility may be a separately contracted paid engagement. Launch and Build have acceptance gates. Operate is a contracted ongoing service with continuous review. A product change requires a new scoped Launch, or Build against an accepted change blueprint.

Start / terminal outcomeActivityScoped serviceDecisionAcceptance gateDeliverableExternal dependencyReturn to earlier stage

Follow the numbered stages in order. Each decision has a named forward path and separate alternative outcomes. Return paths explicitly name the stage they rejoin. A positive feasibility decision is not regulatory approval.

  1. CLIENT OPPORTUNITY

    NEXT: Qualify.

  2. ENTRY & DECISION STAGES

    01Qualify

    Product · buyer · jurisdiction · sponsor · budget

    DELIVERABLE

    Scoped opportunity and commercial fit

    NEXT: Commercial fit?.

  3. Commercial fit?

    YES: Regulatory & delivery feasibility.

    NO · Decline / defer

    End of this route

  4. 02Regulatory & delivery feasibility

    Exact activities · legal route · partners · capacity

    Feasibility may be contracted as a separate paid engagement.

    DELIVERABLE

    Permissible delivery route and dependencies

    EXTERNAL · Qualified specialist and authorised-party assessment where required

    NEXT: Feasible route?.

  5. Feasible route?

    A positive decision is not regulatory approval.

    YES: Launch.

    NO · Redesign

    Return to 02 for another feasibility decision

    Paid feasibility / stop

    A paid investigation may be scoped separately; otherwise this route ends

  6. SCOPED COMMERCIAL SERVICES

    03LaunchSCOPED SERVICE

    Product architecture · flows · RACI · controls · technology & operating model · delivery roadmap

    DELIVERABLE

    Proposed product and operating blueprint

    NEXT: LAUNCH ACCEPTANCE GATE.

  7. LAUNCH ACCEPTANCE GATE

    ACCEPTED: Build.

    NOT ACCEPTED · Revise

    Return to 03 for a revised blueprint

    Stop

    End of this route

    ACCEPTED: accepted product and operating blueprint proceeds to Build.

  8. 04BuildSCOPED SERVICE

    Engineering · integrations · testing · evidence · operating setup

    DELIVERABLE

    Implemented and tested agreed scope

    EXTERNAL · Technology and infrastructure providers under their own contracts

    NEXT: BUILD ACCEPTANCE & RELEASE GATE.

  9. BUILD ACCEPTANCE & RELEASE GATE

    RELEASED: OPERATING HANDOVER.

    NOT READY · Remediate / retest

    Return to 04 and repeat the release gate

    RELEASED: proceed to operating handover.

  10. OPERATING HANDOVER

    NEXT: Operate.

  11. 05OperateSCOPED SERVICE

    Contracted Operating Core + selected modules · monitoring · coordination · reporting · change

    DELIVERABLE

    Accepted contractual operating service

    EXTERNAL · Authorised entity retains regulated activities

    NEXT: Continuous review.

  12. Continuous review

    Review the separate Continue, Change and Exit paths.

    CONTINUE · Operate

    Maintain the contracted service and return to continuous review

    CHANGE · New scoped Launch

    New blueprint and acceptance gate

    CHANGE · Scoped Build

    Only against an accepted change blueprint; repeat Build acceptance and release

    EXIT

    End or transition of the contracted service

Continuous review: CONTINUE maintains the contracted service; CHANGE returns to a new scoped Launch, or to a scoped Build only under an accepted change blueprint; EXIT ends or transitions the service.

  • Not every client follows every phase — the diagram shows the complete delivery lifecycle.
  • A positive feasibility decision is not itself regulatory approval.

02 / REGULATORY & PARTNER MODELS

CASE-SPECIFIC

Who holds the permissions decides the shape.

Partner-led or client-authorised — the regulated perimeter moves, and with it the responsibilities of every other party. Switch models to compare.

CASE-SPECIFIC · CONFIRMED PER PRODUCT AND JURISDICTION

A

Client / product owner

Commercial owner of the product and the customer relationship.

  • Commercial product ownership
  • Brand, distribution and customer experience
  • Agreed product decisions and approvals
  • Agreement with the authorised partner
DECIDES · Commercial decisions and approvals

B

Normexa

Product and operating delivery under a scoped agreement.

  • Product and operating-model design
  • Partner selection support and coordination
  • Technology build within agreed scope
  • Operating Core and selected modules
DECIDES · Recommendations within agreed scope — no regulated decisions
REGULATED PERIMETER

C

Authorised financial partner

Holds the permissions the product requires.

  • Regulated activities under its own permissions
  • Onboarding and risk acceptance where applicable
  • Compliance oversight of the regulated service
  • Regulatory reporting and accountability
DECIDES · Regulated decisions and sign-off
A ↔ C DIRECT AGREEMENT WITH THE AUTHORISED PARTNER
  • The regulated perimeter shows where permissions sit in each model — it is not a legal conclusion.
  • The model for a specific product is confirmed during feasibility, per product and jurisdiction.

03 / DELIVERY RESPONSIBILITIES

SWIMLANE · PARTNER-LED EXAMPLE

Every stage, every party, one line each.

Performs workDecision pointApproval / acceptanceNot involved

Client

Commercial product ownership and agreed decisions

  • QualifyShares opportunity, sponsor and budget; go / no-go
  • FeasibilityProvides facts; chooses the route
  • LaunchMakes product decisions; accepts the blueprint
  • BuildProvides access and user testing; accepts release
  • OperateOwns the product and its governance decisions

Normexa

Contracted product, technical and operating delivery

  • QualifyScopes the opportunity; assesses commercial fit
  • FeasibilityMaps activities, routes, partners and capacity
  • LaunchDesigns architecture, flows, RACI, controls, roadmap
  • BuildEngineering, integrations, testing, evidence
  • OperateRuns the Operating Core and selected modules

Legal / compliance specialists

Relevant professional conclusions and reviews

  • QualifyNot involved
  • FeasibilityProfessional conclusions on the legal route
  • LaunchReviews controls and documentation
  • BuildReviews where required
  • OperateOngoing advice as engaged

Authorised entity

Regulated services, permissions and regulated accountability

  • QualifyNot involved
  • FeasibilityAssesses whether it can support the product
  • LaunchAgrees responsibilities and interfaces
  • BuildOnboards the product into its controls before go-live
  • OperatePerforms regulated activities; holds regulatory accountability

Technology / infrastructure providers

Contracted infrastructure roles

  • QualifyNot involved
  • FeasibilityConfirms capability and constraints
  • LaunchAgrees commercial and technical terms
  • BuildProvides and configures infrastructure
  • OperateRuns contracted infrastructure

Example allocation for a partner-led product. Actual responsibilities are agreed per engagement. Normexa does not perform regulated activities on behalf of the authorised entity.

04 / OPERATING MODEL

OPERATE IN DETAIL →

What happens after handover.

At the release gate, operation moves from project to service. The Operating Core gives it governance, reporting and one change route; modules are added only where the product needs them.

O0

Operating Core

BASE

O1

Product Operations

OPTIONAL

O2

Technology Operations

OPTIONAL

O3

Partner Operations

OPTIONAL

Every engagement starts at Qualify.

Discuss your product