A fintech engineering partner should turn the requirements for your particular business into testable system behaviour. “Fintech” is not a single regulatory category. A financial entity, an ICT supplier to a bank and an early prototype may have different obligations and contractual responsibilities.
Start by agreeing that boundary with your legal, compliance and security owners. Engineering can document data flows, implement controls and rehearse recovery. It cannot determine authorisation requirements or certify an entire business merely by choosing a stack.
Establish who the rules apply to
DORA has applied since 17 January 2025 to financial entities within its scope. A software supplier may face contractual requirements without itself becoming a financial entity.
The Bundesbank's BAIT/DORA explanation distinguishes the transition: institutions subject to DORA's ICT risk-management requirements were excluded from BAIT. Remaining BAIT provisions are due to cease at the end of 31 December 2026. Do not apply both frameworks indiscriminately to every fintech.
For an engagement, record the regulated activity and entity, applicable requirements, system boundaries, critical providers and the person authorised to approve the interpretation. Keep unresolved questions visible before using them as acceptance criteria.
Ask for system-specific evidence
| Area | Engineering evidence to request |
|---|---|
| Identity and access | Permission matrix and tests of denied access, support roles and tenant separation |
| Transaction integrity | Explicit states, duplicate protection, reconciliation and handling of partial failure |
| Change control | Traceable release, approval boundary and recovery procedure |
| Incident response | Detection, escalation, classification responsibilities and evidence timeline |
| Dependencies | Provider inventory, data flows, contractual owner and exit dependencies |
| Recovery | A demonstrated restore and checks of the recovered business state |
These are practical assessment topics, not a claim that every implementation requires the same architecture. A read-only reporting product and a system moving funds have materially different failure consequences.
Build an incident process around actual responsibilities
For major ICT incidents, Delegated Regulation 2025/301 sets reporting stages. The usual initial limit is four hours after major classification and no later than 24 hours after awareness, with specific treatment for later classification. The intermediate stage is tied to the initial notification; the final stage is tied to the intermediate report. The regulation and competent authority's instructions govern the exact case.
The engineering task is to preserve reliable timestamps, identify affected services and releases, and make the relevant information available to the responsible people. Automatic classification is not a universal prerequisite for meeting a deadline. Monitoring, triage, escalation, human decisions and a working submission route must form one process.
Rehearse an incident in which the primary operator or email system is unavailable. Confirm who can obtain access, prepare the report, approve external communication and track the receipt. Avoid filling ordinary logs with customer data merely to make reporting easier.
Assess data handling beyond a region label
EU hosting can be an appropriate requirement for a customer or a chosen operating model. It is not a universal conclusion from the word fintech. Examine data categories, access, subprocessors, backup locations, retention and transfer arrangements. The EDPB's transfer guide explains the separate assessment of transfers outside the EEA.
For onboarding or KYC/AML functionality, identify the business's actual obligations and the approved provider/process. Test incomplete verification, manual review, changed evidence and denied access. Do not confuse purchasing a verification API with completing the customer's whole regulatory process.
Choose a partner for the work it can demonstrate
Request a relevant system walkthrough and a small, agreed assessment of the difficult parts. A general engineering team may implement a well-defined component with specialist oversight. Work involving regulated decisions, money movement or complex oversight may require additional specialist capability. Agree those roles explicitly.
For existing systems, establish repository-to-production parity, account ownership and the next safe release before promising ongoing support. A handover should include known gaps, not just diagrams and credentials.
H-Studio supports custom software, backend engineering and ongoing operation. Scope the technical deliverables alongside your responsible advisers. This guide is engineering information, checked against the linked sources on 5 November 2026, and does not replace legal or supervisory advice.
