From Product Idea to Operating Financial Service

Start with a narrow statement of what will change for whom. Do not start with a technology stack or a list of licences.

Ask:

• Who is the customer and what job does the proposed financial feature perform?
• Which company owns the customer proposition, pricing and distribution?
• What event creates an actual project now: a product launch, a new partner, a new market, a changed customer journey or a recurring operational problem?
• Who can approve the budget, accept the scope and make the product decision?

A bounded first scope might be one customer journey, one product type and one jurisdiction. That does not mean the future business has to remain small; it means the first decision can be tested without quietly expanding the mandate.

Output: a scoped opportunity, named sponsor, commercial objective, assumptions and explicit exclusions.

A statement such as 'we need a bank', 'we need a licence' or 'our partner handles compliance' is not a complete delivery model. The correct question is which exact activity takes place, for whom, in which country and under whose legal responsibility.

Map the real actions in the customer journey: promotion and distribution, onboarding, risk decisions, receipt and movement of money, custody or safeguarding where relevant, execution, servicing and reporting. Separate actions performed by the customer-facing business from actions that must be performed or controlled by the relevant authorised entity.

An existing financial institution may already have permissions relevant to the product; a non-financial company may need an appropriately authorised partner; a new venture may first need to determine whether obtaining its own authorisation is feasible. None of those routes is interchangeable merely because the customer-facing screens look similar.

Qualified legal and regulatory specialists, together with the relevant authorised party, must assess the actual perimeter. A feasibility conclusion is not a regulatory approval.

Output: an activity-by-entity map, jurisdictional boundary, specialist questions and named unresolved decisions.

The proposed operating route needs more than a partner logo on a slide.

For each dependency, confirm the legal entity, service it can actually provide, territorial scope, technical interfaces, willingness to support the proposed arrangement, data/access requirements and commercial conditions. A useful partner may still be unavailable for this particular product or country.

Two common architectures are:

• Client-authorised: the client holds the relevant authorisations and contracts Normexa for precisely agreed product, technical or operational tasks.
• Partner-led: an appropriately authorised external entity provides the regulated services, with product, integration and operational interfaces allocated in the actual contracts.

The licensed entity retains the responsibilities belonging to its regulated role. A contract to integrate that entity's service does not transfer its licence to the technology or coordination provider.

Output: chosen or proposed route, Partner Capability Record, dependencies, decision rights and stop conditions.

A product journey has several layers, and each should be drawn separately before they are combined:

• CUSTOMER ACTION: what the user sees and authorises.
• MONEY / ASSET FLOW: who receives, holds, moves or records what, if relevant.
• DATA FLOW: where information is collected, stored, transformed and shared.
• DECISION FLOW: who can accept, reject, change or reverse a state.
• EVIDENCE FLOW: what proves that a required action or control took place.

A useful model shows exceptional paths as well as the happy path. What if onboarding fails, a payment is rejected, a provider is unavailable or a client changes an instruction? If the product's next state and its owner are undefined, the software specification is incomplete.

For an embedded financial feature, make the boundary between the platform and the authorised entity visible. The customer may interact with one interface while different parties remain responsible for different parts of the service.

Output: versioned journey diagrams, data and financial-flow maps, exceptions and control points.

A single delivery partner can coordinate the programme without becoming the legal owner of every decision.

Create a RACI for each material process rather than one decorative organisation chart. At minimum, distinguish:

• Client/product owner: business objective, product decisions, customer proposition and agreed approvals.
• Normexa: contracted architecture, engineering, integration and operational tasks.
• Legal/compliance specialists: professional advice and mandated reviews within their appointment.
• Appropriately authorised entity: relevant regulated activities, oversight, decisions and retained accountability.
• Infrastructure vendors: their actual contractual technology or service obligations.

Write down who may stop a release or transaction, who responds to an incident, who contacts a customer and who makes any required regulatory notification. The answer may differ by activity and jurisdiction.

Output: a signed, activity-level RACI; decision register; escalation path and contractual interface map.

Implementation should start from an accepted blueprint and a bounded statement of work. A functional demo, a merged pull request or a successful test does not independently demonstrate operational readiness.

Translate the architecture into versioned work packages. Each material workflow should have an owner, acceptance criteria, testing method, evidence location and release dependency. Include access control, reconciliation where relevant, incident handling, recovery and provider failure scenarios.

A useful release record can be concise:

WORKFLOW / CONTROL — EXPECTED RESULT — TEST EVIDENCE — OWNER — STATUS — OPEN RISK

When a control remains open, the release decision must be explicit. An unresolved critical item should not be hidden inside a polished demonstration.

Output: tested implementation of the agreed scope, acceptance evidence, operating runbooks and a controlled release decision.

A financial product does not become finished when its first transaction succeeds.

Before live operation, establish who maintains the service and how its obligations will be evidenced. That includes product changes, support and exceptions, third-party incidents, release management, operational reporting and exit or transition planning.

A modular model can make the service easier to govern. One team may need a common operating register and partner coordination; another may additionally need technology monitoring or product workflow support. The scope, service hours, volumes and responsibilities should match the actual product.

For a managed operating service, distinguish a response-time target from a resolution commitment. Define who supplies information, who has approval rights, how exceptions are escalated and what happens when a provider or the operating partner changes.

The relevant authorised entity must retain the duties and decisions assigned to it by the applicable framework. Operational outsourcing and ICT third-party arrangements may trigger additional case-specific contractual and oversight requirements.

Output: signed operating scope, runbooks, control/evidence register, SLA, escalation and exit plan, and an owner-accepted monthly operating report.