The Software and Systems Engineering Experts
US: +1 (610) 247-9595 / EU: +48 666 74 71 74
Home · Solutions · Banking & Finance
Solutions · Banking & Finance
Banking and finance IT with regulator‑ready change traceability
DORA and EBA guidelines on ICT and security risk management, with evidence from one connected IBM Engineering Lifecycle Management toolchain, set up by consultants who work with banks and financial institutions.
Banking & Finance
The banking and finance sector
Financial services run on software
The sector covers banks, insurers, payment and investment firms, and the ICT providers behind them: core banking, payments, cards, trading and digital channels. Institutions are supervised by national authorities such as the KNF in Poland and by the European supervisory authorities.
Every change to a payment system or a mobile app is a change to a regulated ICT system. Financial entities have to show how each change was requested, assessed, tested, approved and deployed, and how their systems stand up to disruption. A typical pipeline runs from GitLab through HCL AppScan to HCL DevOps Deploy, with each step traced back to the requirement in IBM Engineering Requirements Management DOORS Next.
ShiftDORA in force
ICT risk management, incident reporting, resilience testing and third-party risk now sit under one EU regulation.
ShiftCloud and ICT providers
Critical services move to cloud and outsourced providers, with contracts and oversight that DORA now regulates.
ShiftDevOps in a regulated bank
GitLab pipelines release changes often, and every release still needs a controlled trail of tests and approvals.
ShiftAI in credit decisions
The EU AI Act treats credit scoring of individuals as high risk, with requirements for documentation, data and human oversight.
Engineering challenges
What this means for software and systems engineering
From regulation to requirement
DORA articles, EBA guidelines and KNF recommendations have to become requirements that someone owns and verifies.
Change from request to production
Every ICT change needs a request, a risk assessment, tests, an approval and a deployment record that link together.
Security testing in the pipeline
Security scans with HCL AppScan and functional tests run in GitLab pipelines, and their results have to reach the change record.
Segregation of duties
The person who builds a change should not be the one who approves it for production, and the tools have to show it.
Third-party ICT providers
Requirements for outsourced and cloud services are part of the contract and need the same trace as internal systems.
Legacy and new systems together
Core systems that have run for decades sit next to new digital channels, and one change often touches both.
What auditors and supervisors expect
Where banking teams lose time before an audit
DORA articles and EBA guidelines are mapped to internal requirements in a spreadsheet that is not linked to the systems they cover.
Functional and security test results sit in GitLab and HCL AppScan, and the release approval only says “tested”.
Requirements and test data describe critical systems, and security policy rules out public SaaS tools.
RiskThe bank cannot show which requirement covers an article, or who owns it.
With Smarter ProcessRegulatory articles, internal requirements and controls are linked in IBM Engineering Requirements Management DOORS Next, each with an owner.
RiskAuditors ask for test evidence per change, and it takes days to collect.
With Smarter ProcessHCL AppScan findings, test results and HCL DevOps Deploy records of who deployed what and when are linked to the change request and the requirement, so the release approval shows them.
RiskTool selection stalls in security and outsourcing reviews.
With Smarter ProcessWe install and maintain IBM Engineering Lifecycle Management on the bank’s own servers or private cloud, with access control per project.
Compliance map
DORA, EBA guidelines and KNF Recommendation D, mapped to the toolchain
Pick a standard to see what it asks for, and where it lives in your toolchain once we have set it up.
DORA · Article 9(4)(e)
IBM Engineering Workflow ManagementGitLabHCL DevOps Deploy
What it asks forICT change management: changes recorded, tested, assessed, approved and implemented in a controlled way
How we cover itChange requests linked to requirements, tests and pipeline results; deployments through HCL DevOps Deploy with approvals, audit trail and rollback
IBM Engineering Workflow Management
GitLab
HCL DevOps DeployDORA · Articles 24 and 25
IBM Engineering Test ManagementHCL AppScanIBM Engineering Workflow Management
What it asks forA digital operational resilience testing programme, with tests, findings and remediation recorded
How we cover itTest plans and results for resilience tests, including HCL AppScan vulnerability scans; findings tracked as work items to closure
IBM Engineering Test Management
HCL AppScanIBM Engineering Workflow ManagementDORA · Article 28
IBM Engineering Requirements Management DOORS Next
What it asks forRisks from ICT third-party providers managed, with requirements set before and during the contract
How we cover itProvider requirement modules linked to contract clauses and to their verification
IBM Engineering Requirements Management DOORS NextEBA/GL/2019/04 · Section 3.6
IBM Engineering Requirements Management DOORS NextIBM Engineering Test Management
What it asks forICT projects and changes with defined requirements, testing and approval before production
How we cover itRequirements, test cases, results and approvals in one chain, with test and production releases recorded
IBM Engineering Requirements Management DOORS NextIBM Engineering Test ManagementKNF Recommendation D · Development of IT systems
IBM Engineering Requirements Management DOORS NextIBM Engineering Workflow Management
What it asks forControlled development and change of IT systems, with requirements, testing and acceptance documented
How we cover itRequirement modules, acceptance tests and change requests linked; review and approval records
IBM Engineering Requirements Management DOORS NextIBM Engineering Workflow ManagementPSD2 · RTS on strong customer authentication
IBM Engineering Requirements Management DOORS NextIBM Engineering Test Management
What it asks forStrong customer authentication implemented and tested in every payment channel
How we cover itAuthentication requirements as a module, linked to test cases and results per channel
IBM Engineering Requirements Management DOORS NextIBM Engineering Test ManagementISO/IEC 27001:2022 · Annex A 8.26, 8.29 and 8.32
IBM Engineering Requirements Management DOORS NextHCL DevOps TestGitLab
What it asks forApplication security requirements, security testing and change management in development
How we cover itSecurity requirements linked to security test results and to the change requests that implement them
IBM Engineering Requirements Management DOORS Next
HCL DevOps TestGitLabEU AI Act · Article 11
IBM Engineering Requirements Management DOORS NextIBM Engineering Lifecycle Optimization – Publishing
What it asks forTechnical documentation of high-risk AI systems, such as credit scoring, kept up to date
How we cover itAI system requirements, data and evaluation records in a baseline; documents generated from it
IBM Engineering Requirements Management DOORS Next
IBM Engineering Lifecycle Optimization – PublishingBook a 30-min compliance gap review
Compliance is achieved by your organization and confirmed by your auditors and supervisory authority. Tools hold the evidence; we set them up so the evidence is complete and easy to show.
Capabilities
What your team can do on day one
Baselines for every release
Freeze the requirements, tests and results of each release and compare it with the next one, item by item. Auditors see exactly what changed and who approved it.
- IBM Engineering Lifecycle Management Global Configuration Management
Regulatory requirements with owners
Articles of DORA, EBA guidelines and KNF recommendations are linked to internal requirements and controls, each with an owner and a status.
- IBM Engineering Requirements Management DOORS Next
Change records linked to pipelines
Each change request links to the requirement it serves, the GitLab merge requests that build it and the HCL DevOps Deploy process that releases it, with approvals and rollback.
- IBM Engineering Workflow Management
- GitLab
- HCL DevOps Deploy
Functional and security tests in one place
Automated tests and HCL AppScan results (static, dynamic and open-source analysis) are collected per release, next to the requirements they verify.
- IBM Engineering Test Management
- HCL AppScan
Roles and segregation of duties
Project areas, roles and approval rules keep development, testing and release approval in separate hands, on your own servers.
- IBM Engineering Lifecycle Management
Audit reports from live data
Change, test and coverage reports for auditors are generated from the tools, in your own document templates.
- IBM Engineering Lifecycle Optimization – Publishing
See every product we implement and support
IBM Engineering Lifecycle Management, HCL and GitLab: licences, set-up, training and support from one team.
All products →
Bank operations centreCustomer references
IT and engineering teams in banking
We work with IT teams at Santander and BOŚ Bank on requirements and test management in IBM Engineering Lifecycle Management.
Tracefrom regulation to release
GitLabpipelines linked to change records
On-premiseon the bank’s own infrastructure
FAQ
Questions banking and finance teams ask us
How does the toolchain itself fit into our DORA ICT risk framework?
Like any other ICT system you run. Installed on your servers, IBM Engineering Lifecycle Management is an ICT asset: it goes into your asset inventory, access reviews and backup and recovery tests. If we host it for you, the service is an ICT third-party arrangement, so it goes into your register of information and the contract covers the terms DORA Article 30 requires. We provide the architecture, data flows and recovery procedures your risk team needs for either option.
How do we exchange requirements with ICT providers and outsourcing partners?
Through Requirements Interchange Format (ReqIF) or controlled access to a separate project area, agreed per provider. Each provider sees only the modules and attributes it is allowed to see. Their answers are imported next to the previous delivery, so you see what changed before you accept it. Requirements from the contract stay linked to acceptance tests, which gives your third-party risk team evidence that the provider delivered what was agreed.
We run several releases and environments in parallel. How do we keep requirements and tests in step?
With configurations instead of copies. Each release stream has its own configuration of requirements and tests, and IBM Engineering Lifecycle Management Global Configuration Management records which version of each item it uses. A baseline is frozen when a release goes to production, so you can show later exactly what was approved and tested. A change to a shared requirement shows every release it affects, and each stream takes it on purpose, with a record.
Our requirements are in IBM Engineering Requirements Management DOORS (9.x), with DXL scripts for reports. How do we move?
System by system, not all at once. Systems in the middle of a large release often stay on IBM Engineering Requirements Management DOORS (9.x) until it goes live, while new work starts in IBM Engineering Requirements Management DOORS Next. When a system moves, modules, attributes and links move with their original IDs, and earlier baselines are kept for audit. DXL scripts are inventoried first; most reports become views or document templates, and the rest are rebuilt.
Our developers use Atlassian Jira and GitLab, with HCL AppScan and HCL DevOps Deploy in the pipeline. Do they have to change tools?
No. Regulatory and business requirements, change approvals and test evidence stay in IBM Engineering Lifecycle Management, where auditors need them. Work items stay in Atlassian Jira, code and pipelines in GitLab. We link merge requests, HCL AppScan results and HCL DevOps Deploy deployments to the change request and requirement they belong to. Each release then has one record from requirement to deployment, including who approved and deployed it.
How do we keep evidence for DORA digital operational resilience testing?
As a test programme in IBM Engineering Test Management. Each test, from vulnerability scans and scenario tests to recovery exercises, is a planned test case linked to the critical function and ICT systems it covers. Results and findings are recorded per run, and each finding becomes a work item tracked to closure. The programme, its coverage of critical functions and the status of remediation can then be shown to management and supervisors from the same data.
New · SmarterWidgets 2.0
Ready-made widgets for IBM DOORS Next
Add them to the ELM Mini Dashboard and hand repetitive requirements work over to them. Each one previews its changes first.
Browse all widgets- Content qualityClean text and glossary linksStyle Cleaner, Link Checker and more
- Links and traceabilityFix, move and inspect linksLink Remover, Module To Base Links and more
- Module structureBuild and repair module hierarchyModule Fill, Module Explorer 2.0 and more
- Configuration and governanceBaselines, data models and auditsBaseline Archiver, Compare Data Models and more
- Reporting and publishingCharts, maps and publishingPublishing URLs, Module Insights and more
- See all widgetsScreenshots and details for every widget
Watch and learn
Our Videos
Demos, tutorials and customer stories on requirements, traceability and test.
Talk to our consultants
Leave your details and we will get back to you, usually within one business day.
