Europe already has banks that hold customer accounts and instant-payment infrastructure that moves money quickly. The next competition in person-to-person payments may have less to do with building another rail and more to do with who coordinates identity, consent, risk and transaction certainty between wallets and banks.
In this contributed article, adapted from a written Q&A, Sergei Budnik, a payment solution architect, sets out a vendor-neutral model for wallet-initiated, account-settled payments, and asks who should own the control layer that sits above the rail.
Wallet-initiated, account-settled
In this model a wallet creates and manages the customer-facing payment journey, but does not necessarily hold the balance or move the money. The user selects a recipient and amount in a familiar wallet interface, the wallet builds a structured payment intent and passes it into an orchestration layer, and the payer’s bank then authenticates the customer, checks the account, applies its risk and regulatory controls and executes an account-to-account transfer over existing instant-payment infrastructure.
Some wallets are stored-value products and do hold balances. This is different: it lets a wallet initiate an account-settled payment while the money stays inside the regulated banking system. The customer gets the convenience of a wallet without the wallet provider having to replace banks, become a settlement system or hold another pool of customer funds.
Why Europe may not need another rail
Europe already has the accounts and the instant-payment rails. The friction usually sits above the rail: discovering the recipient, linking a wallet identity to a bank account, proving entitlement to use an account, obtaining trusted consent, passing risk context and establishing the final status of a payment.
Building another rail does not solve those problems; it adds one more network for banks, wallets and processors to integrate. The better question is how to coordinate the capabilities that already exist. The competition may therefore be less about who physically moves the money and more about who defines and operates the rules for when it is allowed to move.
The control layer, and who owns it
The control layer turns a customer action in a wallet into a trusted, executable banking instruction. It would tokenise wallet and account identities, establish proof of ownership, capture and transmit consent, standardise the payment intent, orchestrate risk and fraud signals, select the bank and route, correlate identifiers across parties and maintain transaction state. It should not become a shadow bank, hold balances or take on the bank’s regulatory duties. Its job is coordination: a common language between wallets, banks and rails so that not every participant has to build a bespoke integration with every other.
Who should own it is not, in my view, predetermined. A payment network could run it, because networks already understand interoperability, standardisation and multi-party governance. A processor could offer it as a reusable platform. A consortium of banks could build a shared utility, or a neutral infrastructure provider could operate it. What matters is not the logo above the platform but the governance model. The operator must not use its position to disintermediate banks, restrict wallet access unfairly or take opaque ownership of customer relationships, and the rules for liability, certification, data access, availability, disputes and onboarding must be transparent. Done well, it raises interoperability while leaving banks, wallets and processors to compete on product and experience.
What stays with the banks
Banks should remain responsible for the regulated account and for the decision to execute a transfer: customer identification, account servicing, balance control, anti-money-laundering and sanctions obligations, regulatory reporting and final authorisation. The control layer can pass identity tokens, consent evidence and risk context, but those inputs should support the bank’s decision, not replace it. The bank continues to control the money, the wallet controls the interaction, and the orchestration layer makes sure the instruction between them is standardised, trusted and traceable.
Why transaction certainty decides whether it is safe
A payment is not complete just because a wallet has shown a confirmation screen or an API call returned successfully. A timeout can occur after the bank has accepted the instruction, a response can be lost, a callback can arrive twice, a user can repeat an action, and the settlement rail may have completed a transfer while one party still shows it as pending.
The orchestration layer therefore needs a controlled transaction state machine, end-to-end correlation identifiers, idempotency, duplicate detection and asynchronous status recovery. It must be possible to tell apart a payment that was never submitted, one that was rejected, one still processing, one that completed but lost its response, and one that needs reconciliation. Without that, a wallet-native experience can look elegant and still be financially unsafe.
The strategic question for European payments
For processors, the opportunity is to build a reusable platform rather than a custom integration for every wallet and bank: standard wallet-facing interfaces, bank adapters, payment-intent orchestration, token and consent handling, risk and compliance integration, status management, reconciliation and rail connectivity. The commercial model could combine an integration fee, a platform subscription, a per-transaction charge and optional fees for services such as fraud orchestration or reconciliation. What the processor is really
selling is interoperability, operational consistency and faster time to market.
The wider shift is from asking who will build the next rail to asking who will define the operating model above it. Wallets will compete on experience and convenience, banks will keep the regulated account and execution, and existing rails will keep moving funds. The unresolved layer is the one that coordinates identity, consent, trust, routing and final status across all of them. Whoever builds it well will not replace the ecosystem; the value will come from making it work as one coherent flow. The lasting advantage may lie not in owning the movement of money, but in owning the standards, controls and interoperability that decide
how safely and consistently it is allowed to move.
About the author
Sergei Budnik is a payment solution architect with more than ten years of experience in payment platforms, banking integrations and transaction-processing architecture. His work focuses on payment orchestration, account-to-account and card payment flows, transaction lifecycle management, reliability and operational resilience across banking and fintech environments.
