EKS Rails for PSPs: Architecture and Readiness
“Connecting to a payment system is not a single API project. Licensed providers need a complete operating model around settlement and service continuity.”
Understand the EKS services and access model
Latvijas Banka operates EKS for SEPA clearing and instant payments. The instant service operates continuously. EKS access is governed by its participation rules: a provider may participate directly or be reachable as an addressable BIC holder through an EKS participant, subject to the relevant service and registered arrangement. A project should begin with authoritative requirements and a confirmed legal and settlement model.
Modular Fintech’s payment-rails service can support integration planning, provider abstraction and ledger operations. It does not itself create scheme eligibility or make a client a direct participant.
Design settlement and liquidity before the customer flow
The institution must understand how funds are positioned, how limits are monitored, who acts when liquidity is insufficient and how accounting entries reconcile to settlement evidence. Instant availability increases the importance of out-of-hours ownership and automated alerts for authorised operations teams, but confidential settings should remain within controlled documentation.
Message construction, beneficiary validation, status mapping, returns and exceptions need end-to-end test cases. Every visible customer status should correspond to a state the provider can evidence rather than a convenient front-end assumption.
Prepare for 24/7 operations
Continuous service changes incident response, maintenance and support. The provider needs escalation coverage, cybersecurity monitoring, dependency management and a tested continuity plan. Customer terms should describe availability accurately and distinguish the rail’s operating hours from the provider’s support hours.
Confirm direct-participation or addressable-BIC arrangements for the relevant service.
Map settlement accounts, liquidity ownership and reconciliation.
Validate ISO messages, statuses, rejects and returns.
Test security, resilience and out-of-hours incident handling.
Approve customer claims, fees, limits and launch communications.
Run the programme through connected workstreams
The access workstream confirms eligibility, participation or sponsor arrangements and contracts. Treasury defines settlement accounts, liquidity limits and out-of-hours ownership. Technology implements messages, connectivity, security and observability. Operations designs reconciliation, exceptions, incident response and customer communication. Legal and compliance approve service terms and launch claims.
Dependencies between these workstreams should be visible. A technically successful message test does not prove that liquidity, accounting, support and contractual arrangements are ready. The programme board needs one integrated readiness view rather than separate green reports with unresolved hand-offs.
Use evidence-based go-live criteria
Criteria should cover completed participation steps, security and resilience testing, message certification, ledger reconciliation, liquidity scenarios, reject and return handling, 24/7 incident coverage, customer disclosures and a controlled rollout plan. Residual risks need named owners and acceptance by the appropriate authority.
The first release can limit customers, volumes or use cases while performance and operations are observed. These are internal rollout choices and should not be described publicly as scheme rules. Client communication must state the service actually available on the account.
Keep client education precise
Businesses need to know whether the service they use is enabled and reachable, not every infrastructure detail. Zolvat’s educational article on what EKS means for European businesses [planned internal link — activate after publication] deliberately avoids claiming direct participation or current instant-payment availability.