From Feasibility and Authorisation to Launch-Ready Operations
Build the business, the operating model, the controls and the technology together.
A licence, a registration or a company incorporation is only one milestone. An authorisation certificate does not open customer accounts, underwrite a loan, settle a card transaction, produce a regulatory return or survive an inspection. Around that single milestone a complete institution has to exist.
A new regulated business has to become commercially viable, governable, operational, controlled, staffed, technologically ready, secure, resilient, auditable and genuinely launch-ready — and those things have to arrive together, because each one is evidence for the others. The business plan is part of the licence file. The organisation chart is part of the governance evidence. The IT architecture is part of the resilience evidence.
VODIS works as the senior programme and integration layer that holds those workstreams together: connecting the business model to the regulatory perimeter, the operating model to the technology, and the control framework to the evidence a supervisor will actually ask to see. The strongest practical experience base behind this work is regulated financial services — non-bank financial institutions, consumer and retail finance, microcredit and microfinance-type lending, specialised lending institutions, payment institutions and card-payment businesses.
VODIS is not a law firm and does not provide legal or regulatory opinions. Where those are required, VODIS works alongside the qualified local legal, compliance and regulatory advisers appointed for the project, and supports and coordinates the authorisation process rather than conducting it in their place. Authorisation is always decided by the national competent authority or central bank, where applicable.
Why a Greenfield Regulated Business Is Different
In an established company a change programme can usually assume that most of the organisation already works. In a greenfield build almost nothing is a given: there is no process to improve, no historical data to migrate from, no team that already knows the answer, and no track record to point a regulator at. Everything has to be designed and then evidenced.
The harder problem is that the workstreams are not independent. Decisions taken in one of them silently constrain the others, and a decision taken in the wrong order is usually paid for twice. A few dependencies that recur on almost every build:
- The product model sets the licence perimeter — and the licence perimeter then limits which products may be offered at all.
- Credit policy determines the decision workflow, the data that must be captured at origination, and what collections can realistically do later.
- Any outsourcing decision becomes a regulatory, resilience and contractual question at the same moment it becomes a cost question.
- Payment and card activity ties the product directly to security requirements, settlement operations and platform selection.
- Projected volumes drive staffing, architecture and the cost base together — and an optimistic volume assumption inflates all three.
- Governance and fit-and-proper arrangements have to be real before they can be evidenced, which affects recruitment timing and therefore the critical path.
Feasibility and the Business Model
Before an authorisation programme is worth starting, the business itself has to make sense — commercially and operationally, not only strategically. The feasibility stage exists to establish whether the proposition can work, what it will take, and what the sponsor is actually committing to.
Depending on the project, this typically covers:
- Market, target customers and the problem the proposition actually solves.
- Product proposition and the intended service perimeter.
- Revenue model and cost model, including the costs created by regulation itself.
- Projected volumes and unit economics under more than one scenario.
- Funding and capital assumptions, and what they imply for sequencing.
- Break-even scenarios and the sensitivities that move them most.
- Build, buy or outsource decisions for each major capability.
- The regulatory perimeter implied by the proposition.
- A feasibility study, an implementation roadmap and an indicative investment envelope.
- Sequencing, dependencies and the decisions that have to be taken first.
These are planning instruments, not forecasts of results. VODIS does not promise financial returns, and a feasibility study that produced guaranteed numbers would be worth less, not more.
The Regulatory Path and the Authorisation Programme
Requirements differ substantially by jurisdiction and by licence type, so the first task is to establish what actually applies to this entity in this country — not what applied to a comparable project elsewhere. From there the authorisation effort can be run as a programme with a dossier, an evidence base and a schedule, rather than as a document-writing exercise.
Workstreams that commonly form part of that programme:
- Licence and regulatory perimeter assessment for the intended activity.
- An authorisation roadmap aligned to the national competent authority or central bank, where applicable.
- Dossier structure and an evidence register that maps every requirement to its proof.
- Business-plan inputs prepared to the standard the file requires.
- Governance arrangements, including board and committee structures where applicable.
- Coordination of fit-and-proper evidence for proposed officers.
- Risk management framework appropriate to the activity and its scale.
- AML and KYC framework where applicable to the licence.
- Internal control framework and the three-lines arrangements behind it.
- Outsourcing and third-party model, with the regulatory consequences made explicit.
- Cyber, resilience and business-continuity evidence.
- Operational procedures and the IT architecture documentation that supports them.
- Regulatory and financial reporting readiness.
- Handling of regulator questions, with action and remediation tracking through to closure.
VODIS supports, structures, prepares and programme-manages this work. It does not obtain licences, and no adviser can promise an authorisation outcome: the decision belongs to the competent authority. Specialist legal and regulatory opinions remain with the qualified advisers appointed for the jurisdiction.
Target Operating Model and Organisation
A regulator does not authorise an idea; it authorises an organisation that can run the activity and be held accountable for it. The target operating model is where the business model becomes a working institution with named responsibilities.
This normally includes:
- Governance model, with board and committee arrangements where applicable.
- Executive responsibilities and the mapping of regulatory functions to real people.
- Organisation structure and the reporting lines behind it.
- Roles, responsibilities and the staffing model through ramp-up.
- Job profiles for the positions the authorisation file depends on.
- Process ownership and decision rights, documented rather than assumed.
- PMO and transformation governance for the build itself.
- Policies and procedures, written to be usable by the people who will follow them.
- Training, and the operational handover from the build team to the running organisation.
Lending, Consumer Finance and Microcredit Operations
For lending institutions the operating detail is the business. A credit product is a chain of operational steps, each of which has to be designed, supported by a system, controlled and reported on.
Typical scope:
- Origination and the channels through which applications arrive.
- Eligibility rules and their implementation in the decision path.
- Underwriting, scoring where used, and manual override handling.
- Credit-decision governance, mandates and exception management.
- Contract generation, consent capture and the documentary trail.
- Disbursement and the controls around payment release.
- Servicing, rescheduling and customer-initiated changes.
- Collections and recovery, including early arrears treatment.
- Customer care and complaints handling with the required records.
- Accounting, reconciliation and the link to the general ledger.
- Regulatory and statutory reporting derived from operational data rather than reconstructed later.
Payment and Card Operations
Payment institutions and card businesses add a second operational dimension: money movement in near real time, with settlement, scheme and security obligations attached. The scope depends on whether the entity issues, acquires, processes, or combines these.
Depending on the model, this covers:
- Customer onboarding appropriate to the payment activity.
- Card and payment lifecycle management end to end.
- Issuing, acquiring and processing relationships according to the chosen scope.
- Settlement arrangements and the operational calendar they impose.
- Reconciliation across scheme, processor, ledger and bank accounts.
- Fraud management and transaction security.
- Customer operations and servicing for payment products.
- Disputes and chargebacks where relevant to the model.
- Processor and vendor integration, including testing and certification effort.
- Operational controls and the monitoring that proves they work.
Technology and Data Foundation
A new institution needs a platform landscape rather than a product. The point is not to assemble the longest list of systems but to decide which capabilities genuinely need a dedicated system, which can share one, and which can wait until after launch.
The landscape usually spans:
- Enterprise and application architecture, with the integration model defined early.
- Core lending or loan-management platform, where the activity requires one.
- Payment and card platforms according to the licence perimeter.
- CRM and digital onboarding, including identity verification.
- AML and KYC tooling where applicable.
- Finance, general ledger and ERP, with the accounting model agreed before configuration.
- Risk systems, collections support and document management.
- Workflow and BPM where processes cross system boundaries.
- Integration and API layer, and the data warehouse or data platform behind reporting.
- Management reporting and regulatory reporting, treated as separate obligations.
- Identity and access management, cybersecurity tooling and monitoring.
- Workplace and end-user services, ITSM, backup and recovery, and observability.
The VODIS principle here is deliberate and it rarely changes: technology selection starts from business and regulatory requirements, not from vendor catalogues. A platform chosen before the requirement is understood becomes a constraint that the operating model then has to work around for years.
Infrastructure, Cloud, Data Centre and Resilience
Hosting decisions are regulatory decisions as much as technical ones, because they determine where data sits, who can reach it, and how quickly the business can recover. They are also expensive to reverse once the platforms are live.
As applicable to the entity:
- Hosting strategy and the cloud, data-centre or hybrid model that follows from it.
- Network, connectivity and the resilience built into both.
- Environment strategy, with production and non-production genuinely separated.
- Backup, disaster recovery and tested continuity arrangements.
- Security architecture, monitoring and alerting.
- Capacity planning aligned to the volume assumptions in the business plan.
- Premises and general services where the project includes them.
- The support model that will operate all of it after go-live.
Where the entity and jurisdiction bring it into scope, digital operational resilience requirements — including DORA where it applies — are treated as part of the design rather than as a later compliance exercise. Whether it applies at all is established per entity, not assumed.
Procurement and Vendor Selection
Greenfield builds buy most of their capability. The quality of those purchases, and of the contracts behind them, determines a large part of what the institution can do later and what it will cost to change course.
A structured selection normally includes:
- Requirements defined well enough to be answerable, and traceable to the business case.
- RFI and RFP process management.
- Evaluation criteria and a scoring model agreed before proposals arrive.
- Demonstrations run against real use cases rather than vendor scripts.
- Architecture and integration due diligence.
- Commercial comparison on total cost, not licence price.
- Vendor selection and, where needed, separate implementation-partner selection.
- Outsourcing implications and the regulatory treatment they trigger.
- Contract dependencies, service levels and the licensing or subscription model.
- Exit and portability considerations agreed while there is still negotiating leverage.
Where the project replaces or extends a core platform, this connects directly to the approach described on the Core Business Applications page.
The Programme and Build Office
The distinctive difficulty of a greenfield build is not any single workstream — specialists exist for all of them. It is that a dozen workstreams have to converge on one date, with dependencies that cross every boundary and evidence that has to be consistent across all of them.
VODIS can coordinate that convergence across business, regulatory, risk, compliance, organisation, technology, cybersecurity, operations, data, facilities and general services where relevant, procurement, vendors, testing and readiness. The focus is on the few things that actually determine the outcome:
- Dependencies made visible early, especially the ones that cross workstream ownership.
- Decision gates with named owners, so that decisions are taken rather than deferred.
- A single evidence base serving the authorisation file, the control framework and the audit trail.
- Programme governance that reports the real position, including what is not on track.
- Risk and issue management with escalation that works in practice.
- Change control over scope, because an unmanaged scope change moves the launch date silently.
Operational Readiness and Launch
Readiness is not the moment the systems are installed. It is the moment the organisation can actually run the business on them, under its own controls, with its own people, and keep doing so on the second day.
Readiness work typically covers:
- Processes and procedures proven end to end, not only documented.
- Systems configured, integrated and tested against real scenarios.
- People trained, with roles and mandates actually assigned.
- Vendors ready, including support arrangements and escalation paths.
- Controls operating and producing evidence.
- Reporting — management, regulatory and statutory — producing correct output from live data.
- Security and resilience verified rather than assumed.
- Operational rehearsal and dry runs before cutover.
- Cutover planning and go-live governance with clear decision authority.
- Early-life support and hypercare, with issue tracking and remediation of regulatory actions.
No launch is risk-free, and any adviser who says otherwise is selling something. The purpose of readiness work is to know what the remaining risks are, to have decided who owns them, and to have the means to respond quickly when something does go wrong.
A Repeatable Greenfield Launch Model
Greenfield builds repeat more than they appear to. The regulation, the market and the products differ, but the structure of the problem — feasibility, authorisation, operating model, technology, readiness — recurs. VODIS therefore works through four modular offers, which can be taken in sequence or individually.
Each is scoped and priced per engagement; no pricing is published here, because the scope depends entirely on the licence type, the jurisdiction and how much of the organisation already exists.
1. Greenfield Launch Blueprint
A bounded, self-contained study that a sponsor, investor or group can buy before committing to a full implementation. Its purpose is to replace conviction with a defensible plan — and, where the answer is negative, to establish that early and cheaply.
Typical outputs:
- Feasibility assessment and the business model behind it.
- Regulatory-path map for the intended activity and jurisdiction.
- Target operating model at the level needed for decisions.
- Workstream architecture for the build.
- Initial organisation design and the critical early roles.
- High-level control model.
- Target technology architecture.
- Sourcing and procurement plan.
- Implementation roadmap with sequencing and dependencies.
- Indicative investment and timeline assumptions, stated as assumptions.
- Major dependencies and the risks most likely to change the plan.
2. Authorisation and Build Office
Integrated programme coordination across the authorisation dossier and the parallel institution build, run as one effort because they depend on each other: the file describes the institution that the build is simultaneously creating.
This offer typically covers:
- Programme structure, plan and governance for both tracks.
- Dossier and evidence management against the requirement set.
- Coordination of the specialist contributions the file requires.
- Build-side coordination across organisation, technology, operations and controls.
- Dependency and decision management between the two tracks.
- Regulator question handling, with tracked remediation.
- Readiness reporting to the sponsor, board or group.
The qualified legal, compliance and regulatory advisers retain their specialist roles throughout. VODIS coordinates and prepares; it does not substitute for them, and the authorisation decision remains with the competent authority.
3. Launch Readiness and Stabilisation
For an entity that is already building, or already authorised, and needs to reach a controlled, credible go-live — and then survive the first weeks of real volume.
Scope usually includes:
- Readiness assessment across process, system, people, control and vendor dimensions.
- Gap identification and remediation planning with owners and dates.
- Operational rehearsal and dry runs.
- Cutover planning and go-live governance.
- Early-life stabilisation and hypercare.
- Post-launch issue management and the handover into business as usual.
4. Country and Market Replication
For a group taking an existing business model into another country. The value here is in being deliberate about what genuinely transfers and what does not — and this is not a copy-paste exercise.
What can usually be reused, with validation:
- Operating-model patterns and the structure of the organisation.
- Architecture and integration approach.
- Requirements, where the product is genuinely the same.
- Workstream structure and programme method.
- Control and evidence structure.
- Templates, checklists and procurement artefacts.
What has to be established locally, every time: regulation and law, product rules, reporting and accounting and tax treatment, language and customer expectations, available vendors, and hosting or infrastructure constraints. Every jurisdiction requires validation of the whole model, not confirmation of the parts that were convenient. A reused artefact that was never re-tested against local requirements is a liability, not an accelerator.
Where the Methodology Applies Beyond Financial Services
The same greenfield discipline supports selected non-financial businesses, where the central challenge is to create a new operating organisation and a technology platform from nothing rather than to satisfy a financial supervisor.
Modules that transfer directly:
- Feasibility and business-model work.
- Target operating model and organisation design.
- Process design and process ownership.
- Architecture and integration planning.
- Sourcing and procurement.
- Cybersecurity, data and infrastructure foundations.
- Programme governance and launch readiness.
The honest qualification matters here: the depth of practical experience is not equal across every sector. Regulated financial services is the strongest base, and a non-financial engagement is approached on the strength of the method and the senior experience applied to it, not on a claim of equivalent sector history.
How VODIS Works on a Greenfield Build
The role is adapted to what the project actually lacks, which is rarely the same twice. Depending on the engagement, VODIS may act as:
- Senior adviser to the sponsor, board or group.
- Greenfield programme integrator across the full set of workstreams.
- Build office or PMO for the institution being created.
- Business-technology translator between the commercial, regulatory and technical sides.
- Architecture coordinator across platforms and vendors.
- Vendor-selection support through requirements, evaluation and contracting.
- Interim or fractional transformation leadership for a defined period.
- Assembler and coordinator of a specialist team for the engagement.
That last point reflects how VODIS genuinely operates. Specialist teams are assembled per engagement from appropriate senior experts and delivery partners, according to the scope of the work and their availability. VODIS does not maintain a large permanent employee bench, and does not present one.
Experience Behind the Approach
The method described on this page is not theoretical. It is informed by programmes led or coordinated by the VODIS founder in prior executive and senior-management roles, before VODIS existed as an advisory practice. Those programmes are described here as professional background, not as VODIS client engagements.
The experience most directly relevant to a greenfield regulated build includes:
- A start-up consumer-finance institution, built and brought to operation.
- A greenfield card-payments institution.
- Enterprise functions setup and reorganisation in a newly formed structure.
- Core banking and enterprise platform transformation.
- Mission-critical financial services data-centre work, where resilience was the requirement rather than a feature.
Further detail on these programmes is set out under Selected Executive Experience. Where a programme predates VODIS, it is attributed to the founder's prior roles; it is never described as a VODIS delivery or as work for a VODIS client.
Starting the Conversation
The most useful first discussion is usually narrow: what is being built, in which jurisdiction, under which licence if that is already known, and what already exists — a sponsor decision, a draft business plan, a shortlist of platforms, or nothing at all.
From there it is normally possible to say quickly whether a Greenfield Launch Blueprint is the right starting point, whether the project needs an authorisation and build office, or whether the immediate problem is readiness for a launch that is already close.
