Short answer
Financial services website development is now shaped by rules with dates attached. PCI DSS script controls became mandatory on 31 March 2025, the European Accessibility Act started applying on 28 June 2025, and WCAG 2.2 added an authentication criterion that lands directly on login.
Key takeaways
- 01PCI DSS requirements 6.4.3 and 11.6.1 became mandatory on 31 March 2025.
- 02The European Accessibility Act covers consumer banking and e-commerce from 28 June 2025.
- 03WCAG 2.2 added nine success criteria, including accessible authentication at level AA.
- 04OWASP rates broken object level authorization as easy to exploit and widespread.
Your payment page scripts are now in scope
Two PCI DSS requirements stopped being best practice and became mandatory on 31 March 2025. Requirements 6.4.3 and 11.6.1 exist because, as the PCI Security Standards Council puts it, scripts running in a consumer's browser are now a significant target for attackers seeking to steal payment card data. Between them they require that payment page scripts are authorised, checked for integrity, and monitored for tampering and unauthorised changes to the page.
Accessibility stopped being a preference
The European Accessibility Act started applying on 28 June 2025. It is not a web-only rule, but the web is where most of it lands: consumer banking, e-commerce, e-books, transport information and the 112 emergency number are all named in scope, and the online operations associated with managing financial services have to be accessible along with the contracts for taking those services out. The Commission frames the reach as more than 440 million citizens, including roughly 100 million people with disabilities.
For a bank, an insurer or a lender operating in the EU, the marketing site, the application form and the customer portal are all the same regulated surface. Treating accessibility as a late QA pass is now a compliance decision rather than a quality one.
Login is the hardest surface to get right
WCAG 2.2 became a W3C Recommendation on 12 December 2024 and added nine success criteria. Three of them press on exactly the flows financial services are built from — authentication, long multi-step forms, and dense tables of controls. None of these is exotic engineering. They are the places where a security team's instincts and an accessibility standard disagree, and that disagreement has to be resolved deliberately rather than by whoever ships last.
| Success criterion | Level | Where it applies |
|---|---|---|
| 3.3.8 Accessible Authentication (Minimum) | AA | Login and step-up verification |
| 3.3.7 Redundant Entry | A | Multi-step account opening |
| 2.5.8 Target Size (Minimum) | AA | Dense transaction tables and controls |
The API behind the page
OWASP puts broken object level authorization first in its 2023 API Security Top 10, rating it easy to exploit, easy to detect and widespread. The attack is unglamorous: change an identifier in a request and see whose record comes back. On a financial portal, the identifiers are account numbers, statement references and application IDs — the exact values a URL tends to expose. OWASP's remedy is to check authorisation in every function that uses client input to reach a record, prefer unpredictable identifiers, and write tests that block a deploy when they fail.
Speed is measured on real visits
The last constraint is not regulatory but it is measured the same way. Core Web Vitals set LCP under 2.5 seconds, INP of 200ms or less and CLS of 0.1 or less, each assessed at the 75th percentile of real page loads and split between mobile and desktop. A rate calculator that shifts under the reader's thumb fails on stability, not on styling — and it does so for the three quarters of visitors the threshold is designed to protect.
None of this is a reason to slow a project down. It is a reason to write the four constraints into the brief on day one. See how we approach financial and fintech work, web development and custom software, or start a conversation.
Frequently asked questions
It depends on how the page is embedded and which SAQ you validate against. The March 2025 changes tightened SAQ A eligibility so merchants must confirm their site is not susceptible to script attacks affecting their systems. Confirm your scope with your acquirer rather than assuming.
It applies to products and services placed on the EU market, so serving EU consumers matters more than where the company is registered. If you take applications or payments from customers in the EU, plan on being in scope.
AA is the level nearly every procurement process and regulation references, and it is where the new authentication and target size criteria sit. AAA is optional and rarely required in full. Build to AA and document the exceptions honestly.
Take a valid session for one customer and replay every endpoint using a second customer's identifiers. Anything that returns data rather than an error is a finding. OWASP's advice is to run these as tests that block deployment.
Which regulators and standards apply to your product, and who signs off on the payment page. Those two answers set the scope of the build, and getting them late is what turns a launch date into a compliance problem.
Sources
Keep reading
Enterprise Application Development: What Actually Decides the Outcome
The framework your vendor prefers is close to irrelevant. Integration surface, access control and who answers the pager decide whether an enterprise application lasts.
What an Ecommerce Web Design Company Is Actually Selling You
Most of what you buy from an ecommerce web design company isn't design. Four things decide whether the build holds up — and none of them are in the portfolio.
What SaaS Application Development Services Decide First
Multi-tenancy is not a feature you add in version two. It is the decision every other decision depends on, and the one that is most expensive to reverse.
Stop thinking about it.
Start building.
Talk with us — free consultation, no commitments.