Build Operate Transfer for Financial Services IT
Financial services has the oldest enterprise IT estate of any industry. IBM z/Series mainframes running COBOL process the majority of the world's banking transactions daily. PL/1 actuarial systems at insurers have been in continuous production since the 1980s. Legacy Java applications on WebLogic and JBoss handle custody, settlement, and risk calculation at banks that have spent the past 15 years saying they will replace them next year.
These systems are not being replaced on any near-term horizon. The COBOL mainframe running core banking at a large retail bank will be running in 2035. The question is who maintains and evolves it.
The Build Operate Transfer (BOT) model builds a permanent delivery center for financial services IT: a team of COBOL, legacy Java, and regulatory data engineers who know the institution's systems, work under the institution's direct technical direction, and become direct employees at Transfer. The provider handles employer-of-record, compliance, and operational overhead during the Operate phase.
Below: how BOT works for financial services IT, covering legacy systems, regulatory data engineering, cloud transformation, and the compliance requirements that financial institutions bring to any offshore engagement.
Why Financial Services IT Is a BOT Problem
The skill shortage in COBOL is not cyclical. The average age of a COBOL developer in Western Europe is over 50. Universities stopped teaching COBOL 20 years ago. As this generation retires, the institutional knowledge of core banking systems — batch dependency maps, settlement logic, edge cases in payment processing — goes with them. Eastern Europe retains concentrations of COBOL engineers who entered the profession when these stacks were still being actively built and taught.
DORA, BCBS 239, IFRS 9/17, MiFID II, EMIR, Solvency II — the regulatory workload in European financial services is not shrinking. Each regulatory change requires IT implementation. Regulatory reporting and data quality obligations generate continuous development demand on data engineering and legacy system teams. This is permanent work.
Large banks and insurers prefer to own their IT capabilities. Permanent outsourcing of core systems generates regulatory and operational risk that boards are increasingly unwilling to accept. BOT provides the path from outsourced to owned: building a delivery center that the institution takes over, without absorbing the setup complexity and employer-of-record risk from day one in an unfamiliar jurisdiction.
Systems Covered in a Financial Services BOT Center
| System category | Technologies | Financial services use case |
|---|---|---|
| Core banking | COBOL, IBM z/Series (zOS) | Account management, payments, ledger, batch settlement |
| Actuarial systems | PL/1, COBOL, proprietary actuarial platforms | Policy administration, reserving, claims modelling |
| Settlement and custody | Legacy Java (J2EE), SWIFT interfaces | Securities settlement, custody, reconciliation |
| Risk and quant | Python, C++, R, custom quant platforms | VaR, stress testing, derivatives pricing, IFRS 9 models |
| Regulatory reporting | Python, Databricks, Snowflake, custom reporting | COREP, FINREP, MiFID II transaction reporting, EMIR |
| Data platform | Databricks, Snowflake, dbt, Azure Synapse | BCBS 239 data aggregation, risk data warehouse |
| Cloud platform | Azure, AWS | Cloud migration, data lake, microservices |
| Finance ERP | SAP S/4HANA Finance | Financial consolidation, cost accounting, regulatory GL |
COBOL Mainframe: Core Banking and Settlement
IBM z/Series mainframes running COBOL process the majority of retail and corporate banking transactions in Western Europe. Visa, Mastercard, and national payment schemes route through mainframe-based core banking. Batch settlement — the overnight processing of millions of transactions, position updates, and interest calculations — runs in COBOL.
What COBOL mainframe maintenance involves in banking
- COBOL application development: new features, regulatory changes, product configuration in core banking
- JCL (Job Control Language): batch job scheduling, step sequencing, dependency management
- VSAM and DB2 z/OS: mainframe file system and database maintenance, query optimisation
- CICS transaction server: online transaction processing, screen handling, BMS maps
- MQ and Connect:Direct: mainframe messaging and file transfer for payment interfaces
- Assembler (BAL): performance-critical routines, system exits, low-level debugging
Why BOT fits COBOL maintenance
A BOT center accumulates COBOL system knowledge in a way that contract staffing cannot. The most dangerous aspect of COBOL mainframe maintenance is not the syntax — it is the undocumented business rules embedded in programs that were written by engineers who are no longer available. A BOT center that maintains a COBOL system for 24–36 months, with a structured documentation mandate built into the Operate agreement, converts implicit knowledge into documented runbooks, batch dependency maps, and program inventories. These documents transfer to the client at the same time the employment contracts do.
Legacy Java in Financial Services
Financial services institutions built Java middleware extensively between 1998 and 2012. WebLogic, JBoss (now WildFly), and WebSphere application servers hosting J2EE applications handle custody, trade confirmation, risk aggregation, and client reporting at banks across Europe.
These applications are difficult to replace because:
- They are tightly coupled to mainframe interfaces (MQ, Connect:Direct, file-based)
- They implement complex financial logic (settlement netting, position keeping, P&L calculation) that is incompletely documented
- The downstream systems that consume their outputs depend on specific data formats and timing
A BOT center for legacy Java financial services typically covers:
- J2EE application maintenance (WebLogic, JBoss, WebSphere)
- Spring Boot microservices migration (strangler-fig pattern)
- SWIFT message handling (MT, MX, ISO 20022)
- FIX protocol implementation (trading systems connectivity)
- Kafka-based event migration from legacy JMS
Regulatory Data Engineering
European financial institutions face the most demanding data engineering requirements of any sector:
BCBS 239 — Risk Data Aggregation and Reporting. Requires banks to produce accurate risk reports within defined timeframes. The data engineering challenge: aggregating risk data across multiple source systems, applying agreed definitions, and producing COREP/FINREP reports with full lineage and auditability.
IFRS 9/17 — Financial instrument and insurance contract accounting standards. IFRS 9 requires expected credit loss (ECL) modelling that draws on historical loan performance data. IFRS 17 requires granular insurance contract data that most core policy administration systems were not designed to produce.
MiFID II / EMIR — Transaction reporting. Every financial instrument transaction must be reported to a Trade Repository within T+1. The data engineering challenge: extracting transaction data from front-office systems, enriching with LEI, ISIN, and counterparty data, and transmitting in the required XML format.
A regulatory data engineering cohort in a financial services BOT center:
| Layer | Technologies | Regulatory use case |
|---|---|---|
| Ingestion | Databricks, Kafka, custom mainframe extractors | Core banking, risk systems, front-office |
| Processing | Databricks, dbt, Python | BCBS 239 aggregation, ECL calculation, report generation |
| Consumption | Power BI, custom regulatory portals | COREP, FINREP, EMIR reports |
| Governance | Collibra, Great Expectations, Apache Atlas | Data lineage, data quality, regulatory audit trail |
Cloud and Platform Engineering
Financial services cloud adoption has accelerated, with Azure dominant in European banking and AWS strong in investment banking and capital markets. BOT centers for cloud engineering in financial services cover:
- Azure/AWS landing zone: multi-account architecture, security groups, network segmentation (compliant with EBA cloud outsourcing guidelines)
- DevSecOps: security embedded in CI/CD pipelines, vulnerability scanning, secret management (Vault)
- Data lake on cloud: Azure Data Lake, AWS S3 with Lake Formation, Delta Lake on Databricks
- Microservices: strangler-fig migration of legacy Java services to Spring Boot on Kubernetes
- SRE: reliability engineering for payment systems and trading platforms
EBA cloud outsourcing guidelines require financial institutions to maintain documented exit plans from cloud providers — a requirement that a BOT center's Transfer clause partially satisfies, since the institutional knowledge and control of the cloud estate moves to the client at Transfer.
Cost Benchmarks
Indicative monthly per-head BOT rates for a financial services IT delivery center in Romania:
| Role | Romania gross salary (€/month) | BOT per-head rate (est.) |
|---|---|---|
| COBOL Developer / z/OS (senior) | €4,500–€7,000 | €5,800–€9,100 |
| PL/1 Developer (senior) | €4,000–€6,500 | €5,200–€8,500 |
| Legacy Java Developer J2EE (senior) | €4,000–€6,500 | €5,200–€8,500 |
| Regulatory Data Engineer | €4,500–€7,500 | €5,800–€9,800 |
| Data Engineer (Databricks/Snowflake) | €4,500–€7,000 | €5,800–€9,100 |
| Python Developer (quant/risk) | €4,500–€7,500 | €5,800–€9,800 |
| Azure Cloud Engineer (certified) | €4,000–€6,500 | €5,200–€8,500 |
COBOL engineers in London run £70,000–£110,000 per year. In Frankfurt, €65,000–€100,000. The Romania BOT rate for an equivalent profile is approximately 50–60% lower, with no external manager margin at Transfer.
Compliance Requirements for Financial Services BOT
DORA (Digital Operational Resilience Act) — Effective January 2025. Financial institutions must apply ICT third-party risk management requirements to BOT providers. The BOT contract must address sub-outsourcing controls, audit rights, incident reporting obligations, and business continuity requirements. DORA Article 30 mandates specific contractual provisions for critical ICT outsourcing; BOT agreements for systemically important IT functions fall in scope.
EBA Outsourcing Guidelines — The BOT provider is a third-party service provider. Financial institutions must conduct due diligence before engagement, maintain a register of all outsourcing arrangements, assess concentration risk, and retain sufficient oversight capability to replace the provider if required. The BOT model's Transfer clause directly addresses the recovery capability requirement.
Data residency and sovereignty — For EU financial institutions, all customer data and regulatory data must be processed within the EU. Romania is an EU member state; data processed by a Romanian BOT center does not require cross-border data transfer authorisation. This is a compliance advantage over Indian or Philippine delivery locations for EU-regulated data.
Background screening — Financial services-grade background screening applies to all engineers joining a BOT center with access to production financial data. Credit checks, criminal record checks, and employment verification are standard. The employment framework annex must specify screening standards and the provider's obligation to maintain them for the duration of the engagement.
Frequently Asked Questions
How does DORA affect BOT arrangements for banks?
DORA classifies BOT providers as ICT third-party service providers. Financial institutions must: conduct pre-engagement due diligence, include DORA-mandated clauses in the BOT MSA (audit rights, sub-outsourcing controls, incident reporting, exit planning), maintain the arrangement in their ICT outsourcing register, and assess whether the arrangement is "critical" under DORA Article 31. Critical ICT arrangements require enhanced monitoring and may trigger regulatory notification. The BOT model's Transfer clause directly addresses the DORA exit planning requirement — the institution can execute Transfer and become independent of the provider as a built-in contractual outcome.
Does Romania have COBOL mainframe expertise for financial services?
Romania has COBOL talent with financial services exposure from shared service centers established by European banks and from domestic Romanian banking operations. The COBOL pool is smaller than Java or SAP markets — sourcing requires active headhunting. Engineers with z/OS (JCL, CICS, VSAM, DB2 z/OS) expertise alongside COBOL application development are the target profile. For a 6–10 person COBOL center, Romania is viable. Poland also has financial services COBOL talent. For 15+ COBOL engineers, a multi-country sourcing approach is more reliable.
How is regulatory reporting data handled in a BOT center context?
Regulatory data — COREP, FINREP, EMIR — is among the most sensitive data in financial services. The BOT center's data governance framework must specify: data classification levels, access control by role, data handling procedures for regulatory data, retention and deletion policies compliant with relevant regulations, and audit log requirements. The BOT provider must conduct annual data security training for all engineers with regulatory data access. These obligations should be in the employment framework annex, making them contractual employment conditions rather than voluntary guidelines.
Can a BOT center handle both legacy COBOL maintenance and cloud modernisation simultaneously?
Yes, and this is the most effective structure for financial institutions running long-term modernisation programs. The center operates two cohorts: a COBOL maintenance team sustaining the production mainframe, and a cloud engineering team building the replacement platform. The co-location of both cohorts allows knowledge transfer — COBOL engineers who understand settlement logic can collaborate directly with the Java microservices engineers building the replacement settlement service. This reduces the risk of the cloud team building a service that does not replicate the nuanced behaviour of the COBOL system it replaces.
What happens to COBOL system documentation at BOT transfer?
Incomplete COBOL documentation is the primary risk in any financial services BOT Transfer. The BOT contract must mandate progressive documentation during the Operate phase — not a documentation effort at the end. Required outputs: program inventory with functional descriptions, batch job dependency maps (which jobs must complete before which others can start), known failure mode register (what causes what type of batch abend and what the recovery procedure is), interface inventory (what systems connect to the COBOL system, what data flows, in what format), and runbooks for production support. These documents are formal handover deliverables, not optional outputs.