Proposals answered within 2 business days
Industries

Finance and insurance

Systems, integrations and AI for banks, insurers and fintechs. DORA and supervisory requirements are built in from the analysis stage.

Context

In banks, insurers and leasing companies, a large part of the work still relies on documents and core systems developed over decades. A credit application, a claim report or an AML alert passes through several applications and several pairs of hands before a decision is made. Every change in such a system requires testing and approval from the security team, so new features arrive more slowly than the business expects.

We build applications and integrations that run alongside core systems and, where it makes sense, AI solutions for working with documents and alerts. We work with the client's IT and with the people responsible for compliance and security. Data can stay within the institution's infrastructure, and we set out the processing location and the chain of subcontractors in the contract.

Challenges in the industry

01

Core systems and batch exchange

Instant payments, PSD2 and digital channels need data in near real time. Some transaction and policy systems still exchange data in nightly batches, and every change in them goes through a long testing cycle.

02

Documents covered by secrecy

Applications, certificates and claim files arrive as scans and PDFs in many formats. Staff retype data by hand, while banking or insurance secrecy and GDPR limit where and by whom these documents can be processed.

03

AML alerts and false positives

Transaction monitoring rules generate many alerts, and analysts spend most of their time on routine cases. Every improvement has to be validated and documented, because the decision to report to the GIIF (the Polish Financial Intelligence Unit) stays with the institution.

04

Reporting from multiple sources

FINREP and COREP in banks, QRT in insurers, and reports for the board and risk are built from data spread across core systems, the data warehouse and spreadsheets. Before each deadline, departments reconcile figures by hand. Since 2025 there is also the register of information on contracts with ICT third-party providers required by DORA.

Use cases

Where we deploy software and AI

Data extraction from applications and documents

The model reads data from applications, certificates and identity documents, compares it with the data in the system, and flags gaps and inconsistencies. It runs in an agreed location, without sending documents to external services. An employee verifies the result and approves the case.

Shorter application handling time

Claims handling support

A claim report is classified by type and complexity, and documents are filed with the fields already filled in. The system compares the report with the policy history and industry data, including data from the UFG (the Insurance Guarantee Fund). Simple claims follow a streamlined path, while unusual cases go to the fraud prevention team.

Faster handling of simple claims

AML alert prioritisation

The model ranks transaction monitoring alerts by risk, using the customer's history, linked parties and analysts' earlier decisions. It does not close alerts on its own. The analyst sees the reasoning behind the score, and every decision is recorded in the audit trail.

Analysts start with the highest-risk cases

Knowledge assistant for employees

An AI assistant answers advisers' and agents' questions about products, terms and procedures based on internal documents. Every answer links to its source, and the scope of access matches the employee's permissions. The tool is internal and does not talk to customers.

Consistent answers without searching the intranet

API layer over core systems

We expose core system data and operations through a controlled API to the mobile app, online banking, intermediaries, partners and payment service providers, using the PolishAPI standard. The core system stays unchanged, and new channels use a single integration point.

New features without touching the core system

Regulatory reporting and the DORA register

A shared data model shows the lineage of every figure: which system it came from, when, and after which transformation. The same data feeds reports for the supervisor and the board, as well as the register of contracts with ICT third-party providers, including subcontractors and processing locations.

Less manual reconciliation before deadlines
Compliance and security

Regulatory requirements are taken into account from the analysis stage

DORA and ICT third-party providers

DORA has applied since 17 January 2025 and covers ICT risk management, incident reporting, resilience testing and oversight of third-party providers. As a provider, we supply data for the register of information, support incident handling, and accept audit rights and an exit plan in the contract, to the extent required for critical or important functions.

After Recommendation D: cloud and outsourcing

Together with DORA, the KNF (the Polish Financial Supervision Authority) repealed Recommendation D, the IT guidelines for insurers and the KNF cloud communication. For banks, the rules on outsourcing in Articles 6a-6d of the Polish Banking Law still apply. Solutions can run in a public cloud, a private cloud or the institution's own infrastructure, and the contract sets the data location and subcontractors.

AI Act, scoring and life insurance

AI systems that assess the creditworthiness of individuals, or evaluate risk and pricing in life and health insurance, fall into the high-risk category under Annex III. Systems that detect financial fraud are an exception. After the 2026 changes, the obligations for this category apply from 2 December 2027. We design documentation, event logging and human oversight from the start.

Banking and insurance secrecy and GDPR

Customer data is protected by banking secrecy (Art. 104 of the Banking Law) or insurance secrecy (Art. 35 of the Act on Insurance and Reinsurance Activity), as well as by GDPR. We process it in the institution's environment or in a dedicated cloud region, with pseudonymisation where possible, under a contract that sets the location and subcontractors.

How we start

01

Workshop with business, IT and compliance

We agree the process, the metric and the owner of the solution on the institution's side. Security, compliance and risk are at the table from the start, because their input changes the architecture.

02

Risk assessment and architecture

We help assess whether the solution supports a critical or important function within the meaning of DORA, whether an AI system falls into the high-risk category, and which data is covered by secrecy. On that basis we set the processing location, the choice of models and the audit trail.

03

Pilot in shadow mode

The solution first runs in parallel with the current process and does not affect decisions. We compare its results with employees' decisions and extend the scope only after the process owner approves.

04

Rollout, documentation and maintenance

We hand over documentation for internal audit and the supervisor, put model quality monitoring in place, and maintain the system under a service agreement with an agreed SLA. The contract includes an exit plan with a handover of code and data.

FAQ

Frequently asked questions

By default, no. We run models, including language models, in the institution's infrastructure or in a dedicated cloud environment in a chosen region. If the institution decides to use an external API, the contract sets the location, subcontractors and audit rights.