Application for Banking License: IT & IS Framework
Applying for a banking (or PSP/EMI) license requires more than capital and governance. Supervisors expect a risk-based IT & Information Security pack that shows how your technology, third parties, and controls support business strategy and meet legal duties on Information and Communication Technology (ICT) risk, outsourcing, and operational resilience.
Investors who enter projects aimed at obtaining a banking, EMI, or PSP license often underestimate the true scope of resources required. While attention is usually focused on regulatory, legal, and capital requirements, the IT dimension is frequently overlooked or treated as secondary. In reality, the technological backbone, including infrastructure, security, and compliance with regulatory standards, constitutes one of the most substantial and complex components of the licensing process. Failure to properly assess and budget for these IT requirements at the application stage not only delays approval but also jeopardizes the financial viability of the entire venture.
​
This article outlines the core content regulators and investors expect at submission, and a practical process to plan and manage activities with the license team.
Analysis and Research Phase
Translate business, compliance, non-functional, and information-security inputs into a clear IT & IS scope and a regulatory map. In this phase we identify the license and jurisdictions, build a compact compliance matrix, capture business requirements (products, channels, geographies, volumes), draft NFRs (availability, RTO/RPO, latency, data residency), list processes and external integrations/data flows, and define governance (CIO/CTO, CISO, DPO, decision rights).
Business Strategy Analysis
Captures the bank’s business strategy and product scope and aligns them with the ICT strategy. Forms the foundation for the target architecture, delivery roadmap, and budget.
Non-functional Requirements
Specify the quality attributes and operational constraints of the system—how it must perform. Typical NFRs include performance, scalability, security, reliability, usability, and maintainability.
Compliance Documents Research
Maps the business and IT scope to applicable regulatory requirements and clarifies what must be included in the license application. Getting this wrong triggers regulator queries or rejection.
Information Security Requirements
Define information-security requirements by mapping regulatory obligations and recognized standards to our scope. Consolidate data protection and security into baseline controls, policies, and training commitments for the application.
Documents Development Phase
Produce the IT documentation based on the captured requirements. This documentation set is reviewed and approved by the client’s license team.
Business Description
Describes target client segments, banking products, and core business processes. Serves as a prerequisite for solution architecture and vendor communication.
​
Regulatory Map
List of IT-related regulatory requirements with links to official sources from the licensing authority.​
​
​
Target IT Architecture
The blueprint of IT banking solutions, data flows, internal/external integrations supporting operations. The diagram is the starting point for budget estimation and resource planning.
Indicative Budget
Translates the IT scope into an indicative CapEx/OpEx budget that demonstrates sufficient resources to meet regulatory and digital-operational-resilience obligations (e.g., EBA ICT, DORA).
Reference for Information
Core document for engaging potential vendors and shaping the indicative IT budget. Unlike an RFP, an RFI does not oblige you to select a vendor.
​
​
IT & IS Application Pack
Consolidates the IT & IS deliverables and aligns them with the investor’s business plan; submitted to the supervisor as part of the license application.
​
Conclusion
A strong license application requires a concise, risk-based IT & IS pack that proves governance, shows a coherent target architecture, sets measurable NFRs, lists key policies and third-party dependencies, describes incident reporting and data protection.
​
When these elements are consistent and proportional to the business, supervisors can quickly see that ICT risks are understood and managed, reducing clarification rounds and accelerating the overall assessment.
At the same time, investors gain a clear view of the funding required to build and operate the IT backbone of a modern financial institution.