REGULATED FINANCIAL PRODUCT STUDIO
REGULATED PRODUCTS.
Designed to be built and operated.
Normexa helps financial operators, non-financial businesses and new ventures bring financial products to market. We connect product design, the regulatory operating model, appropriately licensed partners, technology and ongoing operations into one working system.
02 / WHO WE WORK WITH
Different starting points.
One integrated approach.
Commercial ambition, regulatory structure, partners, technology and operations have to work together. Where you start changes the route, not the requirement.
A
EXISTING OPERATION
Extension
Financial operators
New products, changed journeys, distribution, providers or operating models — added to a system that already runs.
EXTEND AN EXISTING SYSTEM
B
YOUR PLATFORM
Regulated service layer
Non-financial businesses
Embedded or branded financial features for software, marketplaces and merchants — often through an authorised partner, not your own licence.
CONNECT A REGULATED LAYER
C
COMMERCIAL · REGULATED · TECHNICAL
New structure
New financial ventures
Founders, corporate groups and investors creating a new financial business — one coordinated route from concept to operation.
ASSEMBLE A NEW STRUCTURE
03 / THE PROBLEM WE SOLVE
Financial products don't operate in isolation.
The product, the regulated entity, the software, the counterparties and the daily operation have to form one coherent system. Each specialist can be excellent — the gaps sit between them.
WITHOUT A COORDINATING ARCHITECTURE
- ?Which entity performs onboarding — and on whose policy?
- ?Who owns a failed payment once the product is live?
- ?Which controls does the software have to evidence, and to whom?
ONE COORDINATED ARCHITECTURE
- Product & customer journeyCLIENT
- Regulated activitiesAUTHORISED ENTITY
- Legal & compliance conclusionsSPECIALISTS
- Software & integrationsNORMEXA · PROVIDERS
- Counterparties & partnersCOORDINATED BY NORMEXA
- Daily operationsOPERATING CORE
Every function has a named owner, a defined interface and evidence of how it works.
04 / WHAT WE DO
From idea to operating financial product.
Three offerings on one architecture. You do not need all three — but what is decided in Launch is what Build implements and what Operate runs.
Launch
Define the product, regulatory route and delivery model.
YOU RECEIVE · Accepted product & operating blueprint
EXPLORE LAUNCH
Build
Implement the agreed workflows, technology and integrations.
YOU RECEIVE · Implemented and tested agreed scope
EXPLORE BUILD
Operate
Run the agreed operating model through modular services.
YOU RECEIVE · Accepted contractual operating service
EXPLORE OPERATE
05 / HOW WE WORK
A practical path from opportunity to operations.
Two entry stages decide whether and how a product can be delivered. Three scoped services then deliver it — each closed by an acceptance gate.
01
Qualify
Scoped opportunity and commercial fit
02
Regulatory & delivery feasibility
Permissible delivery route and dependencies
03
Launch
Proposed product and operating blueprint
04
Build
Implemented and tested agreed scope
05
Operate
Accepted contractual operating service
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.
- CLIENT OPPORTUNITY
NEXT: Qualify.
ENTRY & DECISION STAGES
01QualifyProduct · buyer · jurisdiction · sponsor · budget
DELIVERABLE
Scoped opportunity and commercial fit
NEXT: Commercial fit?.
- Commercial fit?
YES: Regulatory & delivery feasibility.
NO · Decline / defer
End of this route
- 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?.
- 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
SCOPED COMMERCIAL SERVICES
03LaunchSCOPED SERVICEProduct architecture · flows · RACI · controls · technology & operating model · delivery roadmap
DELIVERABLE
Proposed product and operating blueprint
NEXT: LAUNCH ACCEPTANCE GATE.
- 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.
- 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.
- BUILD ACCEPTANCE & RELEASE GATE
RELEASED: OPERATING HANDOVER.
NOT READY · Remediate / retest
Return to 04 and repeat the release gate
RELEASED: proceed to operating handover.
- OPERATING HANDOVER
NEXT: Operate.
- 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.
- 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.
06 / REGULATED DELIVERY MODELS
The right operating model for the product.
Different products need different regulated routes. Some run under an appropriately licensed partner; others under the client's own authorisation. We make the roles, interfaces and decision boundaries explicit before anything is built.
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
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
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
- 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.
07 / OPERATE
Built for ongoing operations.
Every Operate engagement starts with the Operating Core. Product, technology and partner modules connect to it only where the product needs them. Select modules to see how a scope is composed.
Product Operations
- Customer journey and product support
- Product changes and releases
- Operational controls evidence
- Product performance reporting
Technology Operations
- Monitoring of agreed systems
- Vendor and integration management
- Release and environment management
- Access administration
Partner Operations
- Partner interface management
- Agreed reporting to the authorised entity
- Onboarding and offboarding coordination
- Oversight evidence packs
EXAMPLE SCOPE · O0 Operating Core + O1 Product Operations + O3 Partner Operations
Module scope, pricing and service levels are agreed per contract. No universal all-inclusive operating promise.
08 / OUR INTERNAL VENTURES
Building financial infrastructure from within.
Alongside client work, we develop our own financial-infrastructure projects. They are internal, and they are labelled that way.
FinLattice
INTERNALFinancial structures, decision paths, evidence and wrapper architecture held in one model.
INTERNAL PROJECT · NOT A CLIENT OFFERING
Treasury Lane
INTERNALCorporate liquidity flows across bank and financial partners, governed by operating controls.
INTERNAL PROJECT · NOT A CLIENT OFFERING
Allocra
INTERNALPortfolio information, financial data and investment-research architecture.
INTERNAL PROJECT · NOT A CLIENT OFFERING
09 / EXPERIENCE & PRINCIPLES
ABOUT NORMEXA →Built through technology and finance.
Normexa's experience spans financial products, software architecture, entrepreneurship and investment — the disciplines a regulated product needs at the same table, from the first decision to daily operation.
01
Product thinking
Start from the customer, the economics and the journey.
02
Regulatory clarity
Name each regulated activity and who performs it.
03
Engineering discipline
Build what was agreed, test it, keep the evidence.
04
Operational accountability
Design for the day after launch.
Start with a defined problem.
Tell us what you want to build, change or operate. We'll establish the relevant scope, dependencies and next decision.