Eximee Team
As of June 19, 2026, a new rule applies across the European Union: withdrawing from a contract concluded online must be as easy as concluding it. The rule comes from Directive (EU) 2023/2673, which amends Directive 2011/83/EU on consumer rights and repeals Directive 2002/65/EC on the distance marketing of financial services. The key new provision, Article 11a, covers all contracts concluded with consumers through an online interface where a right of withdrawal applies. This includes accounts, cards, loans, and term deposits opened online. The goal is simple: an end to dark patterns, meaning design choices that deliberately make it harder for customers to cancel.
Poland missed the transposition deadline. The first draft of the implementing act was withdrawn, but a new one (UC 169) was submitted for public consultation on September 10, 2026. The direction of change is settled. The only open question is the date.
For an online store, adding a withdrawal button is a relatively simple change. In a bank, a single click triggers customer verification, different legal consequences for different products, and a series of operations in core systems. That is why implementing this function in banking is not a minor UI tweak but a challenge for system architecture and core banking integration. This article shows how to meet it.
The new rules do not change the right of withdrawal itself or its time limit. Instead, they specify what the withdrawal function must look like in the interface.
The function must be labeled “Withdraw from contract here” or with an equally unambiguous phrase. It must be prominently displayed and easily accessible throughout the entire period during which the customer has the right of withdrawal. It cannot be temporarily disabled or made technically difficult to use.
The process has two steps. First, the customer fills in a form, providing information that identifies them and the contract, and indicating the channel through which they want to receive confirmation. Then they submit the statement using a separate, clearly labeled button, such as “Confirm withdrawal.” They do not have to give a reason, and they can withdraw from the contract in whole or in part. The trader must send the customer a confirmation on a durable medium without undue delay, including the content of the statement and the date and time it was submitted.
The new function does not replace existing withdrawal methods, but a bank cannot redirect a customer who concluded a contract online to a branch or a call center. The rules tie the function to the interface through which the contract was concluded. Some banks take a broader interpretation and make the function available in every digital channel where they sell products, which reduces the risk of claims that customers had to search for the right place.
For the financial sector, one more element matters: the proposed Article 42a of the Polish Consumer Rights Act, which explicitly prohibits dark patterns in financial services. The directive lists examples such as giving more prominence to certain choices, repeatedly asking customers to make a decision they have already made, and making it harder to cancel a service than to sign up for it. So the button alone is not enough. The entire journey before and after it matters.
In everyday language, both terms mean “canceling a product,” but legally and procedurally they are two very different paths. For a bank designing a withdrawal function, the distinction is crucial because it determines which products belong in the form, at what point, and with what consequences for the customer.
| Withdrawal from a contract | Termination of a contract | |
|---|---|---|
| Basis | Statutory consumer right | Contract terms and product-specific regulations |
| When | Within the statutory period, typically 14 days (longer for some products or if the customer was not properly informed) | At any time during the contract |
| Reason | Not required | Depends on the contract, usually not required |
| Legal effect | The contract is deemed never to have been concluded | The contract ends after the notice period |
| Settlement | Repayment of principal, interest for the actual period the funds were used, refund of fees | According to the contract terms |
| Interface button | Mandatory, with two-step confirmation | Not required by the directive, but recommended as good UX practice |
In practice, the withdrawal form must clearly communicate the period within which withdrawal is available and, once that period has passed, direct customers to the termination path. Less stringent requirements for termination do not mean anything goes, however. The dark patterns ban also covers situations where canceling is harder than signing up. A bank that perfects its withdrawal journey but leaves termination behind a call center may still have a problem.
In e-commerce, withdrawal usually ends with the return of goods and money, whether the customer bought a pair of shoes or a coffee maker. In banking, the challenges come from four areas:
Each of these challenges can be solved on its own. The difficulty lies in solving them all at once, in a single, consistent process available in every channel.
The first decision concerns the approach: a form added separately to each sales process, or a single solution for all products.
The siloed approach seems natural because, in many banks, each product is managed by a different unit, and sales processes developed independently. The result is easy to predict: each form works a little differently, each must be maintained and updated separately whenever regulations change, and there is a growing risk that the function will simply not be built in one of the channels. That is exactly the kind of gap the rules do not tolerate.
The platform approach means one form for all products sold remotely. In Eximee, its logic is designed once and published simultaneously in online banking and the mobile app. The platform is integrated with the bank’s app once, and subsequent forms, including the withdrawal form, can be launched in the mobile version without additional integration work. With minimal effort, the same form can also be made available in advisor channels, such as the call center and branches. The rules do not require this, but if a customer calls or visits a branch, an advisor can take their statement within the same process, and the bank keeps a single, consistent workflow across all channels.
Implementation experience shows, however, that the biggest challenges are not technological:
Until now, each unit in the bank collected a different set of data needed to process a withdrawal. With one form for many products, the biggest challenge wasn’t the technology. It was standardizing those requirements so that each product needed a similar set of data.
Adam Ziemkiewicz, Eximee Platform Product Owner at Consdata
Eximee does not remove these organizational divisions, but it ensures the customer does not feel them. For the customer, it is a single form. On the bank’s side, each statement goes to the unit responsible for fulfilling the request.
A good journey is short, predictable, and, as far as possible, the same for all products.
The function should be where customers look for it: in the product details or in the product management section. The rules do not specify a number of clicks, but best practice is no more than two or three. The option must not be hidden in terms and conditions, multi-level menus, or behind a chatbot.
The customer selects a product from a full list and then identifies the specific contract. Depending on the product, this is an account, a card number, or a contract number. Where the API allows, the form suggests ready-made options, such as a list of accounts or cards. Where it does not, for example with term deposits, the customer enters the number manually, and the form shows where to find it. At this stage, the customer also sees hints about the withdrawal conditions for the selected product, such as the time limit.
The customer submits the statement using a separate button. The screen does not need detailed calculations or summaries, because the simpler the process, the lower the risk of the customer getting lost.
The confirmation message should state not only what the withdrawal concerned and when it was submitted, but also what happens next, for example, whether and by when the customer must return funds.
The easiest way to spoil the journey is to try to retain the customer. Retention screens such as “Are you sure you want to lose your bonus?”, a mandatory reason-for-cancellation field, or additional authentication steps may be considered dark patterns. Asking for a reason is fine, but only as an optional field.
Since June 2025, consumer banking services have been subject to the requirements of the European Accessibility Act. The form must therefore work with screen readers, keyboard navigation, and text magnification, and descriptions of the legal consequences should be written in plain language.
From the customer’s perspective, withdrawing from a contract takes a few clicks. On the bank’s side, it is a process that must connect the interface, the systems handling individual products, and customer communication. The key is how responsibility is divided among these elements.
The most important architectural decision concerns where the withdrawal business logic resides. In Eximee implementations, the platform acts as a trigger: it accepts the customer’s statement and creates a task for the appropriate bank system. Stopping interest accrual, changing the product status, and calculating the amount to be repaid remain with the systems that already handle each product. The bank does not have to move or duplicate core banking logic, and each unit processes withdrawals within processes it already knows.
The form displays different fields depending on the product type. If the bank’s system provides the product’s opening date, Eximee retrieves it and shows only contracts concluded within the withdrawal period. If not, the form accepts the customer’s statement, and the system handling the withdrawal decides whether the request can be fulfilled. The customer is not blocked at the interface level.
The form uses the active session of a customer logged in to online banking, so the bank knows who is submitting the statement without additional steps.
Eximee connects to the bank’s messaging system via a REST API. The customer receives two messages: one after submitting the statement, with a document and confirmation that the request was received, and another after it is processed, with the status “completed” or “rejected.” The customer does not need to follow up on what is happening with their statement, and the bank has every stage of the process documented.
Data from every request is stored in a reporting database through a platform-level mechanism. The bank has a single place to check who withdrew from which contract and when, which helps with complaints and potential regulatory audits.
Before launching the withdrawal function, it is worth going through the following list. It will help verify that the solution meets regulatory requirements and does not leave gaps that a customer or regulator would quickly spot.
The withdrawal function looks like a small change: one button, one form, one confirmation. In a bank, however, that button is backed by different products, many systems, and many teams that have so far each handled withdrawals in their own way.
A successful implementation rests on three pillars. The first is regulatory compliance: a clearly labeled function, a two-step process, confirmation on a durable medium, and availability throughout the withdrawal period. The second is low maintenance cost: a single form for many products instead of separate solutions, each of which must be updated whenever regulations change. The third is a consistent UX free of dark patterns: a short, predictable journey that is the same in every channel, with no attempts to retain the customer.
The Polish regulations implementing the directive are still being drafted, but their direction will not change. Banks that prepare now will avoid a last-minute rush when the act comes into force and will build a solution that also brings order to how product cancellations are handled.
Are the Polish rules on the withdrawal function already in force?
Not yet. Directive 2023/2673 was to apply from June 19, 2026, but Poland did not transpose it on time. A new draft implementing act (UC 169) was submitted for public consultation on September 10, 2026. The obligation to provide the function, and the ability of UOKiK (the Polish Office of Competition and Consumer Protection) to enforce it, will arise once the Polish act comes into force.
What is the difference between withdrawing from a contract and terminating it?
Withdrawal is a statutory consumer right that can be exercised within a set period, typically 14 days, without giving a reason. The contract is then deemed never to have been concluded. Termination is possible at any time during the contract, on the terms set out in it, and the contract ends after the notice period. The directive requires a button only for withdrawal.
Does the customer have to give a reason for withdrawing from a contract?
No. The right of withdrawal applies without the need to give a reason. A bank may ask for one, but only in an optional field. A mandatory field could be considered an obstacle to withdrawal.
Does the withdrawal function have to be available before logging in to online banking?
The rules do not specify this. They require the function to be clearly visible and easily accessible. In banking, the natural place is the logged-in area, such as the product details or the product management section, because the bank must identify the customer and the contract. The key is that the customer can reach it in a few clicks.
Can a bank require additional authentication for withdrawal?
A bank must be sure that the statement is submitted by the customer, which is why it usually relies on the customer’s active online banking session. However, any additional step may be considered an obstacle. A sensible rule: withdrawal should not require more authentication steps than concluding the same contract did.
How quickly must a bank confirm a withdrawal?
Without undue delay after the statement is submitted. The confirmation must reach the customer on a durable medium and include the content of the statement and the date and time it was submitted. It is also good practice to include information on next steps.
Can a single form handle withdrawals from all of a bank’s products?
Yes, and this approach has an advantage over separate forms for each product. The customer goes through one journey in every channel, and the bank maintains one solution. In Eximee, the form routes each statement to the unit responsible for the product, while the fulfillment logic stays in the bank’s systems.
