Replacing Your 3D Secure ACS Provider: A Migration and Vendor Evaluation Playbook for Issuers
An ACS demo may look perfect. The real test is whether your next provider can support a safe cutover, a workable operating model and the requirements your bank will face after go-live.
Replacing a 3D Secure Access Control Server involves selecting the right new provider, validating its approvals and integration scope, negotiating data handover and moving live authentication without losing control of cardholder journeys.
The difficult questions are easy to miss: who controls existing enrolment data, which scheme-specific checks are required, what happens to in-flight challenges and how quickly can the team adjust risk rules after cutover?
Below: the migration risks, evidence to request from both vendors and the acceptance tests to run before signing. If you have an active replacement project, use this guide to shortlist providers and scope a technical evaluation.
Active ACS replacement project? Compare vendors against your cutover requirements
If your bank has an existing ACS and is preparing a shortlist, ask each provider for a scoped replacement proposal, not another generic product presentation. The response should cover the proposed ACS version and EMVCo approval, scheme-specific readiness, supported issuer/BIN configurations, data portability, integration dependencies, test environment, operational access and a written cutover and rollback approach.
What to bring to a technical evaluation: current provider model (processor-bundled, managed or self-hosted), target schemes and countries, BIN portfolios, expected authentication volume, deployment preference, existing integrations, contract exit window and planned go-live date. An indicative budget range also helps distinguish a live procurement from exploratory research.
FinOn can discuss product fit and demonstrate documented ACS capabilities against these requirements. The migration scope and timeline are assessed for each project; a demonstration is not a commitment to a particular cutover method or date.
What a shortlisted ACS replacement vendor must demonstrate
Before you select a provider, agree how each candidate will prove five deal-critical requirements:
- Product and scheme evidence. Confirm the exact ACS version and EMVCo Letter of Approval, then request scheme-specific onboarding, testing and operational readiness requirements for your markets.
- Operational control. Ask the vendor to demonstrate a permitted risk-rule change, role-based access and transaction investigation in the proposed admin interface. Document which changes still need vendor assistance.
- Migration feasibility. Request a field-level data inventory, integration map and responsibilities for outgoing-provider handover, authentication continuity and any necessary risk-model recalibration.
- Acceptance tests. Agree representative frictionless, challenge, OOB, timeout, monitoring and rollback scenarios, with pass/fail criteria before cutover.
- Commercial scope. Compare an itemised proposal including implementation, scheme-related work, hosting, operations, support, security responsibilities, changes, and exit terms over a consistent assessment period.
If a vendor cannot provide an actionable answer to these points, the issue is not yet ready for contract signature. Use the rest of this playbook to check the risks in detail.
Signs it is time to replace your 3DS ACS
Most issuers put up with a bad fit far longer than they should. The cost of switching is easy to see. The cost of staying is not.
Six symptoms that usually point to something structural, not something you can fix with a better support ticket:
None of these alone proves you need a new ACS. Use them to build a business case and specify what a replacement provider must demonstrate.
When not to replace your 3D Secure ACS
A lower licence quote is not enough. Compare implementation, testing, coexistence, data handover, operational responsibilities and stabilisation costs against the expected savings. The payback period depends on your actual commercial terms.
Three other cases where staying put is the right call:
- You are mid-way through a protocol upgrade. Finish it, then decide.
- The problem is a rule nobody on your side knows how to change. Fix the access first. You may not need a new vendor at all.
- If a simple portfolio already meets its operational, fraud and compliance needs, replacement may not justify its cost. Test the business case before initiating procurement.
Three starting points, three different migrations
Where you are migrating from changes the project completely. These are three different pieces of work, not three versions of one.
Leaving a processor-bundled 3DS ACS
This can be a complex migration. The ACS may be included in a processing agreement, connected tightly to the processor's platform and governed by the same commercial terms.
What that means:
- Contracts may need separating before any technical work starts
- Card range data and BIN configuration may live on the processor side
- Enrolment, device binding and authentication records may be controlled by the processor or the underlying ACS provider. Check what can legally and technically be transferred.
- The outgoing processor may face contractual, technical or security restrictions on handover. Agree data access, formats, notice periods and transition support in writing.
Start with the contract, not the architecture. Establish what is separable, what notice period applies, and what the processor is obliged to hand over, before you scope anything technical.
Leaving a hosted 3D Secure ACS provider
This may be simpler to scope technically if the ACS is a distinct service with documented integration points, but the actual exit terms and data portability still need verification.
Data access often becomes the limiting factor. Device enrolment, trusted-browser settings, whitelisting and risk-model history may sit with the outgoing provider. Request a field-level data inventory and a sample export early; do not assume portability.
Moving from your own deployment to a vendor
Moving from a self-hosted ACS to a managed provider may shift infrastructure and maintenance responsibilities. The complexity depends on existing integrations, approvals and the contract. Confirm which operational controls the issuer keeps.
If you are weighing this in the other direction, the trade-offs run both ways: ACS as a service versus running it yourself is a separate decision from choosing a vendor, and worth settling first.
What you are actually migrating
Traffic is the easy part. The full list is longer than most scoping exercises assume.
| What | Detail | Where it lives today | Transfers? |
|---|---|---|---|
| Authentication rules | Thresholds, challenge logic, exemption handling | Outgoing ACS | Manually, usually |
| BIN configuration | Card ranges, programme mapping, per-range settings | Outgoing ACS or processor | Manually |
| Enrolled cardholders | Devices, trusted browsers, binding state | Outgoing ACS | Sometimes, by export |
| Whitelisting | Trusted merchant registrations | Outgoing ACS | Sometimes, by export |
| Risk model history | Behavioural baseline the engine scores against | Outgoing ACS | Rarely |
| Branding and copy | Challenge screens, OTP messages, per-programme styling | Outgoing ACS | Rebuilt |
| Scheme-specific readiness evidence | Per scheme, per protocol version | The schemes | Never |
| Logs and audit trail | Required for disputes and regulators | Outgoing ACS | By export, if the contract allows |
The most sensitive items often include enrolment state, risk settings, transaction history and authentication signals. Portability differs by product and contract; their transfer and effect on cardholder experience must be tested.
What happens to enrolled cardholders
This is the part that catches issuers out, and it should be settled before anything else gets planned.
An established ACS may rely on device, browser and behavioural signals available to its risk engine. Check how those signals are sourced and retained, and whether they will be available in the new environment.
A replacement may lack some historical context unless transfer is supported and permitted. Changes in challenge behaviour are possible, not inevitable, so compare pilot results against portfolio-specific baselines.
Continuity checks before and after cutover
Verify what can be retained, what needs reconfiguration, and which metrics require closer monitoring.
If useful signals are lost or reset, authentication behaviour may change after cutover. Measure this through a controlled pilot; do not assume every cardholder will face a challenge.
Five things that make the difference:
- Set initial risk rules according to the issuer's approved risk appetite. Test changes with fraud and authentication teams; do not relax controls solely to suppress challenges.
- Plan for post-cutover stabilisation. Agree which risk settings, models and baselines may need recalibration and how the results will be reviewed.
- Migrate what you can. Some vendors import device binding and whitelisting data. Ask both: the outgoing provider whether they will export it, the incoming one whether they can consume it. Do not assume either answer.
- Track challenge rate and challenge completion together. Investigate changes using segment-level data rather than attributing every movement to the new ACS.
- Tell the fraud team before go-live. A temporary rise in challenges looks like a fraud signal if nobody warned them.
How much of this you can control depends on the risk engine you are moving to. Where the thresholds, device weighting and challenge rules sit in a 3D Secure ACS determines whether the warm-up is something you manage or something that happens to you.
Who owns scheme re-certification
EMVCo product approval does not transfer from one ACS product to another. For a proposed deployment, scheme registration, onboarding, testing or approval may also be needed; obtain written requirements scheme by scheme.
Scheme-related activities can determine the critical path, but timing and responsibilities vary by network, market and implementation. Ask the incoming vendor for a documented, scheme-specific plan rather than assuming a fixed eight-week window.
Three questions clear up most of it:
Who submits? The vendor should provide the current EMVCo approval evidence for the proposed product. Ask each relevant scheme and the implementation parties to confirm who owns registration, tests, approvals and go-live sign-off.
Who pays? Identify scheme fees, external testing, vendor work and internal delivery costs separately. Ask which items are included in the proposed fee and which are charged in addition.
What is the sequence? Scheme-specific checks and durations can differ, including for domestic networks. Build the plan around written requirements and dependencies rather than a uniform certification cycle.
Can individual schemes or BIN portfolios be activated separately under the applicable scheme and operating rules? Confirm this early, because it may determine cutover sequencing.
EMVCo approval versus scheme certification
EMVCo product approval and network-specific operational readiness are different. Buyers should verify the proposed version, intended schemes and deployment scope separately.
| EMVCo approval | Scheme certification | |
|---|---|---|
| What it confirms | The product conforms to the EMV 3-D Secure specification | Your implementation works on that network |
| Who issues it | EMVCo | Each scheme separately |
| Scope | Per product, per protocol version | Per implementation, per scheme |
| Where to check | EMVCo Approved Products Directory, public | Ask the vendor for expiry dates |
| Transfers on migration? | Held by the vendor, not you | Not automatically. Confirm what network-specific onboarding or testing is required. |
A current EMVCo Letter of Approval is necessary product evidence, but it does not by itself establish readiness for every scheme, market or production environment.
And check the approval covers the right product. An approval for a vendor's 3DS Server says nothing about their ACS, and the two are listed separately in the directory.
Card range data synchronisation
Before ACS cutover, issuer/BIN configuration and scheme or Directory Server registrations must route authentication requests to the correct ACS. In EMV 3DS, PReq/PRes card-range data is exchanged between the 3DS Server and Directory Server, not synchronised from the Directory Server into the ACS.
Confirm before cutover:
- Who updates issuer account-range registration and the intended ACS routing for each applicable scheme
- How routing to the new ACS will be tested and monitored before, during and after cutover
- Whether staged activation by scheme or BIN is permitted and how it is confirmed
- Who owns configuration reversal, incident response and monitoring if cutover fails
Combining a vendor change with a 3DS 2.2.0 to 2.3.1 upgrade
If you are on 2.2.0 and the new ACS supports 2.3.1, the question comes up straight away. Both at once, or one after the other?
- Combining the vendor change with a protocol upgrade may consolidate some work, but could also expand the required testing and approvals. Request a scope-based comparison; do not assume a fixed time saving.
- The case against: two variables at once. If the challenge rate moves after cutover, you will not know whether it is the new engine, the new protocol, or the missing cardholder history.
- One option is to migrate on a compatible protocol version, stabilise and then upgrade. Another is to combine the changes when dependencies and scheme requirements justify it. Choose based on documented risks, not a universal rule.
If you do combine them, instrument more heavily and expect a longer stabilisation period.
Phases and timeline
The schedule below is an illustrative workstream, not a standard twelve-week or four-month commitment. Actual timing depends on scheme requirements, integration work, data portability and the chosen cutover approach.
| Phase | Activities | Weeks |
|---|---|---|
| Initiation and planning | Team mobilisation, kick-off, requirements gathering, scope interview, project plan | 1–2 |
| Design and configuration | System architecture design, software configuration, integration setup | 2–3 |
| Testing and QA | Functional testing, performance testing, security testing | 4–5 |
| Scheme certification | Visa certification, Mastercard certification, any domestic schemes | 5–12 |
| Deployment and training | Go-live planning, end-user training, knowledge transfer, deployment | 11–12 |
| Post go-live | Transition to support, performance monitoring, optimisation | 12 onwards |
Illustrative migration workstreams
Sequence and duration depend on scheme requirements, integration scope and data portability.
- Planning & requirementsDefine target schemes, BIN portfolios, responsibilities and acceptance criteria.
- Design & configurationPrepare architecture, integrations, environment and required settings.
- Testing & quality assuranceTest authentication journeys, failure handling, performance and monitoring.
- Scheme-specific readinessComplete any required onboarding, testing or approvals with the relevant networks.
- Training & deploymentPrepare controlled cutover, team handover and rollback procedures.
- Go-live & stabilisationMonitor challenge rates, completion, latency and incidents against agreed baselines.
Three things worth reading off this table:
- In this example, scheme-related tasks occupy a large part of the schedule. Their real duration must be confirmed with the relevant schemes and implementation parties; additional cycles may be needed.
- Go-live preparation can overlap testing only when documented acceptance and readiness gates are met.
- The sample plan does not include the full stabilisation period after cutover. Add monitoring, incident support and agreed exit criteria.
Replacement projects also require contract exit, data handover, coexistence and rollback planning. Request a project plan for your actual scheme and BIN scope.
Have an active ACS replacement project? Share your current provider model, target schemes, BIN portfolios and preferred cutover window with FinOn.
Why cut over BIN by BIN
Cut the whole portfolio over at once and any mistake lands on every cardholder at the same time.
- If scheme routing and the architecture allow staged cutover, start with a controlled, representative segment rather than assuming every BIN range can move independently.
- Agree the observation period, metric thresholds and rollback conditions before each pilot. A seven-day window is only an illustrative planning assumption.
- Expand the rollout based on measured results and programme criticality. Compare each segment with its own pre-migration baseline.
Illustrative staged cutover sequence
Where routing and approvals permit, move through controlled portfolio stages.
- Pilot portfolioStart with a representative lower-impact segment; compare agreed metrics with the existing baseline.
- Additional portfolioExpand once the pilot meets its agreed acceptance criteria.
- Higher-volume segmentValidate performance, authentication behaviour and support readiness before increasing volume.
- Critical programmesMove flagship portfolios only after readiness and rollback gates have been satisfied.
A BIN-by-BIN cutover depends on scheme routing, contractual permissions and integration architecture, not only on ACS multi-BIN support.
In-flight challenges at the moment of cutover
This one only shows up when you are doing it.
A cardholder begins a challenge on the old ACS. They go to find the OTP. Meanwhile traffic switches to the new one. They submit the code, and the system that issued it is no longer receiving.
Settle three things before cutover:
- Does the outgoing ACS keep accepting responses for in-flight sessions, and for how long?
- Is there a drain period where new requests go to the new ACS while existing sessions complete on the old?
- What does the cardholder see if a session cannot complete?
Use a tested process for handling in-flight challenges. The required drain window depends on session timeouts, routing and scheme behaviour, not a universal few-minute duration.
Rollback
Set the conditions before you need them. Deciding what counts as bad enough while it is happening gets you the wrong answer.
Agree in advance:
- Thresholds that trigger rollback: challenge rate, completion rate, latency, error rate
- Who decides, and how fast they can be reached
- How long rollback takes to execute
- Whether rollback is per-BIN or whole-portfolio
And the commercial question: how long does the outgoing ACS remain available, and at what cost? A rollback plan that relies on a system switched off the week before is not a plan.
What stays with the outgoing vendor
This gets negotiated last and badly, for the same reason.
- Logs and audit trail. You will need historical authentication records for disputes and regulators after the system is gone. Establish retention, export format and access period.
- Rule configuration. Your thresholds and logic either belong to you or they do not, depending on what you signed. Find out which before you need to know.
- Enrolled cardholder data. Whether they will export it, in what format, and whether the contract obliges them to.
- Reporting history. Your pre-migration baseline. Without it you have nothing to compare the new system against.
What a replacement ACS provider should prove
Ask for scoped evidence rather than unverified claims about outcomes in unrelated issuer portfolios.
- Operational control: request a live demonstration of authorised RBA rule changes, role-based access, authentication search and reporting, including the operations that still require vendor support.
- Migration execution: request a documented runbook with scheme dependencies, data handover responsibilities, cutover, rollback and acceptance testing. Ask which evidence can be reviewed under NDA.
- Commercial fit: request an itemised three-year cost model, responsibilities, support levels, exit provisions and definitions of any quoted performance metrics.
A strong vendor response shows how these requirements will be delivered for your portfolio, not just a list of generic features.
Questions for your outgoing 3DS ACS vendor
- How long do you remain available after cutover, and at what cost?
- What cardholder enrolment data can you export, and in what format?
- What happens to logs and audit records, and for how long can we access them?
- Who owns the rule configuration under our agreement?
- What notice period applies and what triggers it?
- Will you support in-flight session completion during the cutover window?
Questions for your incoming 3D Secure ACS vendor
- Which comparable migrations can you document, and what practical evidence can we review under NDA?
- Do you have a documented migration plan, or is it assembled per client?
- What can you import: device binding, whitelisting, rule configuration?
- What data can be retained, what risk-model recalibration may be required, and which post-cutover metrics will trigger review?
- What is the exact EMVCo Letter of Approval for the proposed ACS version, and what scheme-specific onboarding remains?
- Which scheme and domestic-network activities are required, with owners, costs and acceptance evidence?
- Can we activate specific schemes or BIN portfolios independently, where permitted, and what dependencies could block that?
- What does your test environment include: a real 3DS Server and Directory Server, or ACS-side stubs?
- What is the tested rollback procedure, who authorises it and how quickly can the relevant routing be restored?
FinOn 3DS ACS supports multi-issuer and multi-BIN configurations, configurable RBA managed in the admin interface, and cloud, on-premises or hybrid deployment. Request a technical demonstration against your migration requirements rather than a generic feature tour.
Who does what
| Stage | You | Outgoing vendor | Incoming vendor | Scheme |
|---|---|---|---|---|
| Contract exit | Lead | Confirm terms | – | – |
| Data export | Define needs | Execute | Define format | – |
| EMVCo LOA | Verify | – | Hold and provide | Publish |
| Scheme certification | Programme details | – | Product evidence | Assess and approve |
| Rule replication | Own and approve | Provide current config | Implement | – |
| Account-range routing | Request and monitor | – | Configure ACS for BIN ranges | Update Directory Server registration |
| Testing | Define scenarios | – | Provide environment | – |
| Cutover | Decide sequence | Drain window | Execute | – |
| Rollback | Decide | Remain available | Execute | – |
| Stabilisation | Own thresholds | – | Support | – |
Metrics for the first weeks
Measure against each BIN range's own pre-migration baseline, not the portfolio average.
| Metric | What a problem looks like |
|---|---|
| Challenge rate | Rises and does not settle within the agreed warm-up |
| Challenge completion | Falls. Cardholders are abandoning, not just being challenged |
| Frictionless rate | Does not recover as history builds |
| Authentication latency | Approaches checkout timeout thresholds |
| Error and timeout rate | Anything above the old baseline |
| Authorisation approval rate | The number the business actually cares about |
Watch the last one hardest. Every authentication metric can look fine while approval rate slides, and approval rate is the number finance will ask about.
Whether you can see any of this by BIN range, geography and device depends on the reporting the new system gives you. It is worth confirming before signature rather than after.
Frequently Asked Questions
How long does a 3D Secure ACS migration take?
There is no universal ACS migration duration. Timing depends on the existing provider's exit terms, data portability, issuer integrations, scheme-specific checks, acceptance testing and cutover approach. Ask shortlisted vendors for a milestone plan with named owners, prerequisites and a realistic stabilisation period.
What happens to cardholders who have already enrolled devices?
Device binding, trusted-browser settings and risk history may or may not be portable, depending on the system, contract and permitted data handling. A new ACS may operate with fewer historical signals, but a challenge-rate increase is not automatic. Confirm export/import capabilities, run a representative pilot and monitor segment-level results.
Who is responsible for scheme re-certification during a 3DS ACS migration?
The incoming vendor should provide approval evidence for the proposed ACS product; issuer, processor, vendor and relevant schemes must agree any required registration, onboarding, certification or testing for the new deployment. Record responsibility, cost and acceptance criteria separately for each scheme.
Can you migrate a 3D Secure ACS without downtime?
A staged or parallel cutover can reduce disruption where the scheme routing and architecture permit it, but zero downtime cannot be guaranteed without a validated transition plan. Test in-flight challenges, failure handling and rollback against the issuer's production requirements.
Should we change 3DS ACS vendor and upgrade from 2.2.0 to 2.3.1 at the same time?
Combining a provider change with a protocol upgrade can reduce duplicated work in some cases, but may increase test complexity. The actual approval scope and timeline must be confirmed with the relevant schemes and implementation partners; there is no universal eight-week saving.
How do you leave a 3DS ACS that came bundled with your processor?
Start with the processor agreement. Check commercial separation, notice periods, permitted access to enrolment and configuration data, and the processor's handover obligations. Data ownership and portability depend on the underlying contracts and architecture.
What should we ask a new 3D Secure ACS vendor before committing?
Which comparable migrations they can document, whether a documented migration plan exists, what enrolment and configuration data they can import, what risk-model recalibration may be needed after cutover, the exact EMVCo Letter of Approval for the proposed ACS version and the scheme-specific onboarding that remains, what the test environment actually includes, and how rollback is authorised and executed.
Is EMVCo approval the same as scheme certification?
No. EMVCo approval applies to a specified product/version. Card-scheme onboarding, testing and production acceptance are separate, scheme-dependent processes. Confirm which steps and documents the proposed deployment needs rather than assuming all schemes follow one certification procedure.
What is the difference between an ACS and a 3DS Server?
An Access Control Server supports issuer-side cardholder authentication. A 3DS Server initiates EMV 3DS authentication from the acquiring or merchant side. The two components have distinct integration responsibilities and approval evidence.
Is FinOn's 3D Secure ACS EMVCo-approved?
Yes. ACS FINON version 2.3.1 holds EMVCo Letter of Approval 3DS_LOA_ACS_FITC_020301_01044, covering EMV 3DS 2.3.1 and 2.2.0, with an approval expiration date of 26 May 2027. The approval is valid while it is listed in the EMVCo Approved Products Directory. Scheme-specific onboarding for your deployment is confirmed separately.
Can FinOn's 3D Secure ACS be licensed or used as a managed service?
Both. Issuers and processors can license FinOn 3DS ACS for cloud, on-premises or hybrid deployment, or use it as a managed service through 3D Secure as a Service. The right model depends on your operating capacity, data-residency requirements and scheme scope.
Before you start
Three things to settle in week one. Everything else depends on them:
- Verify the incoming vendor's certification yourself in the EMVCo Approved Products Directory. Confirm the approval covers the ACS product and the protocol version you need, not the vendor's 3DS Server.
- Establish what the outgoing vendor will export, in what format, and what the contract obliges them to provide.
- Agree whether partial go-live is possible: one scheme certified while another is not. This determines your sequencing.
About FinOn 3D Secure ACS
FinOn 3D Secure ACS (ACS FINON) is an EMVCo-approved, horizontally scalable Access Control Server for banks, card issuers, processors and BIN sponsors. It is available as a licensed deployment or as a managed service. These are the points from this playbook that you can check against it.
- EMVCo approval
- Letter of Approval
3DS_LOA_ACS_FITC_020301_01044, approval expiration date 26 May 2027. View the LOA and check the listing in the EMVCo Approved Products Directory. - Card schemes
- Certified with Visa, Mastercard, American Express, JCB, UnionPay and mada. Scheme-specific onboarding for your deployment is confirmed per project.
- Multi-issuer and multi-BIN
- Multiple issuers, card programmes and BIN ranges in one platform, each with independent configuration, risk policies and branding.
- Configurable authentication
- RBA rules, thresholds and challenge logic are configured in the admin interface without vendor-side development. Supports OTP, out-of-band app approval, biometrics through the Authentication SDK, decoupled and non-payment authentication.
- Operations and reporting
- Admin interface with RBA settings, user management, transaction search, merchant whitelisting, dashboards, logs and analytics. Runs stand-alone or alongside external fraud engines.
- Deployment
- Licensed for cloud, on-premises or hybrid deployment on Linux or Windows, or managed through 3D Secure as a Service. API-first integration with issuer systems, card management and notification services.
Planning a 3D Secure ACS migration?
Bring your current provider model, target schemes, BIN portfolios and preferred cutover window. Ask the team whether a licensed or managed ACS deployment fits your project and what the proposal includes for integration, operations, security and support.
