Every issuer eventually has this conversation. Someone in a leadership meeting asks, "Why are we paying a vendor for authentication when we could just build it ourselves?" On paper, it sounds reasonable. An Access Control Server (ACS) is "just" a piece of infrastructure that sits in the 3-D Secure flow, checks a few risk signals, and decides whether to approve a transaction or throw up a challenge screen. How hard can that be? 

Very hard, it turns out — and expensive in ways that rarely show up in the first budget draft. 

This blog breaks down what actually goes into building and running an ACS in-house, what the ongoing costs look like once you move past the pilot phase, and how that compares to partnering with a specialized provider like M2P. The goal isn't to tell you build is always wrong — for a handful of issuers, at a certain scale, it genuinely isn't. The goal is to make sure the decision is made with the full picture, not just the sticker price of a vendor contract versus a rough estimate of engineering hours. 

What an ACS Actually Has to Do 

Before getting into cost, it's worth being precise about what an ACS is responsible for, because the scope is wider than most non-specialists assume. 

An ACS sits on the issuer side of the EMV 3-D Secure (3DS) protocol and is responsible for: 

• Authenticating the cardholder during a card-not-present transaction, using data passed from the merchant's 3DS Server and Directory Server (the scheme's DS, like Visa or Mastercard)

• Running risk-based authentication (RBA) — deciding, transaction by transaction, whether to approve frictionlessly or step up to a challenge (OTP, biometric, app-based approval, etc.)

• Maintaining EMVCo certification across every version of the 3DS specification currently in circulation (2.1.0, 2.2.0, 2.3.1, and whatever comes next), because merchants and schemes support multiple versions simultaneously during transition periods

• Maintaining scheme-specific certifications with Visa, Mastercard, RuPay, Amex, and any other network the issuer supports — each with its own testing cycles, technical requirements, and re-certification triggers

• Delivering the authentication UI/UX — the challenge screens themselves, which need to work across mobile browsers, in-app WebViews, and native app-to-app flows, and which directly affect conversion rates

• Meeting uptime and latency SLAs demanded by the schemes — 3DS authentication happens in the critical path of a purchase, so a slow or down ACS doesn't just fail transactions, it fails them in a way that's visible to the cardholder in real time

• Staying compliant with regional mandates — PSD2 SCA in Europe, RBI's Additional Factor of Authentication (AFA) requirements in India, and equivalent rules wherever the issuer operates

• Handling exemptions and liability shift logic correctly, because getting this wrong means the issuer — not the merchant — eats the fraud loss

That's the job description. Now let's talk about what it costs to staff it. 

The Build Case: What's Actually Involved 

Teams that decide to build in-house usually underestimate three things: the certification burden, the ongoing maintenance load, and the fraud-model cold-start problem. Let's take each in turn. 

1. Initial Development and Certification 

Building a 3DS-compliant ACS from scratch is not a weekend sprint. At minimum, the initial build requires: 

• A team of engineers who understand the EMV 3DS message specification in detail (not just the high-level flow, but the specific data elements, message versioning, and error-handling requirements)

• Integration work with every card scheme's Directory Server — and each scheme has its own onboarding process, testing environment, and certification checklist

• EMVCo Letter of Approval (LOA) certification, which involves formal testing against EMVCo's own test suite and is required before you can go live with any scheme

• A security architecture that can pass PCI DSS assessment, since the ACS handles cardholder authentication data

• A risk engine — even a basic one — because an ACS that challenges every single transaction will tank conversion rates and generate cardholder complaints almost immediately

• A hosted, redundant infrastructure setup capable of meeting scheme-mandated uptime (typically 99.9%+) and response-time SLAs, because 3DS authentication happens inline during checkout

Realistically, this is a 12–18 month build for a competent team before the first live transaction — and that's assuming no major surprises during scheme certification, which is optimistic. Certification testing frequently surfaces edge cases (message format mismatches, timeout handling, exemption logic) that send teams back to the drawing board. 

2. The Certification Treadmill Never Stops 

This is the part that catches teams off guard the most. EMVCo doesn't certify your ACS once and leave you alone. The 3DS specification itself evolves — 2.1.0 to 2.2.0 to 2.3.1, with more versions on the roadmap — and issuers are expected to support multiple versions concurrently because merchants upgrade at different paces. Each new version means: 

• New test cycles with EMVCo

• Re-certification with every card scheme you support

• Code changes to handle new data elements, new exemption categories, and new message formats

• Regression testing to make sure the changes don't break existing certified flows

This isn't a one-time cost baked into the initial build. It's a recurring line item, indefinitely, for as long as you run the ACS. Miss a certification window and you risk being unable to support new merchant integrations, or worse, falling out of compliance with a scheme mandate. 

3. The Fraud-Model Cold-Start Problem 

This is the least visible cost and arguably the most important one. A risk-based authentication engine is only as good as the data it's trained on. A specialized ACS provider that serves multiple issuers is scoring transactions across a much broader and more diverse dataset — different card portfolios, different merchant categories, different fraud patterns across geographies. 

An issuer building an in-house ACS starts with none of that. The risk engine has to learn from the issuer's own transaction history alone, which means: 

• Higher false decline rates in the early months (real customers getting challenged or blocked unnecessarily)

• Higher missed-fraud rates until the model has seen enough fraud cases to learn from

• A slower path to the "frictionless approval" rates that mature ACS deployments achieve, because achieving high frictionless-authentication rates safely requires a mature risk model — not just a rules engine

This cold-start problem doesn't show up in a development budget. It shows up in customer complaints, chargeback rates, and approval-rate metrics for the first year or two of operation — and it's genuinely hard to shortcut. 

4. Ongoing Operational Load 

Once live, an in-house ACS needs: 

• 24/7 monitoring and incident response, since authentication failures during peak shopping hours are a business-critical outage, not a minor bug

• A dedicated team to handle scheme communications, mandate updates, and regulatory changes across every market the issuer operates in

• Continuous fraud model tuning as fraud patterns shift — fraud rings adapt quickly, and a static model degrades fast

• Support for new authentication methods as they emerge — biometric step-up, passkeys/FIDO2, native app-to-app flows — each of which requires its own development and testing effort

• Capacity planning for peak traffic (festive sales, product launches) where transaction volume can spike 5–10x for short windows

None of this is a "set it and forget it" system. It's a permanent product line with its own roadmap, its own on-call rotation, and its own budget cycle — competing for the same engineering resources that could be building the issuer's actual customer-facing products. 

The Hidden Costs Nobody Puts in the First Estimate 

When teams model build-vs-buy, they usually price the engineering hours for the initial build and stop there. Here's what typically gets left out: 

Certification and re-certification fees. Every scheme charges for onboarding and testing, and these recur with every major spec version change and every new market you expand into

Security audit cycles. PCI DSS assessments aren't a one-time gate — they're annual, and the scope grows as your infrastructure grows

Talent cost and retention risk. 3DS and payments-security expertise is a niche skill set. Losing even one or two engineers who understand the certification history and edge cases of your specific implementation can set a team back months

Opportunity cost. Every engineer-month spent maintaining ACS infrastructure is a month not spent on the issuer's core differentiators — new card products, better app experiences, faster onboarding. For a fintech or bank, authentication infrastructure is a compliance necessity, not a competitive moat. Building it in-house means your best engineers are maintaining table stakes instead of building your edge

Downtime and incident cost. When an in-house ACS has an outage during a high-traffic period, the cost isn't just the failed transactions — it's cardholder trust, scheme scrutiny, and potential SLA penalties

Slower time-to-market for new authentication methods. Passkeys, biometric step-up, and app-based approval flows are becoming table stakes for good UX. A specialized vendor rolls these out once and deploys them across its entire issuer base. An in-house team has to build, test, and certify each one independently

Add these up over a 3–5 year horizon, and the total cost of ownership for an in-house ACS is almost always higher than the initial build estimate suggested — often by a wide margin. 

The Buy Case: What You're Actually Paying For 

When you partner with a specialized ACS provider, the license fee or transaction-based pricing isn't just "outsourced infrastructure." You're buying a few specific things that are genuinely hard to replicate in-house: 

Certification maintenance, handled continuously. A specialized vendor is already certified across EMVCo spec versions and every major scheme, and stays current as new versions roll out — because that's the core business, not a side project

A risk engine trained on network-wide data. Because the vendor serves multiple issuers across geographies and portfolios, the fraud model has more signal to learn from from day one. That typically translates into better frictionless-approval rates and lower false-decline rates sooner than an in-house build could achieve

Speed to market. Instead of a 12–18 month build, integration with an existing ACS platform can be measured in weeks, which matters if you're launching a new card product or entering a new market on a deadline

Continuous feature delivery. New authentication methods — passkey support, biometric step-up, richer risk signals — get rolled out to all clients on the platform, rather than requiring each issuer's team to build them independently

Predictable, scalable cost. Instead of a large upfront capital investment plus an open-ended ongoing headcount commitment, the cost structure is typically usage-based and scales with transaction volume — which is easier to plan around and doesn't require permanent in-house specialist teams

Support and accountability. SLAs, uptime guarantees, and dedicated support are part of the commercial relationship — so when something goes wrong, there's a team whose job is to fix it, rather than pulling your own engineers off other priorities

This is exactly the role M2P's ACS is built to play — EMVCo and scheme-certified, built for issuers and BaaS platforms that want strong authentication without carrying the certification and fraud-modeling burden in-house, with the flexibility to plug into existing card programs quickly. 

When Building In-House Might Actually Make Sense 

To be fair to the "build" side of the argument: there are situations where it holds up. 

• Extremely large issuers with enough transaction volume to train a competitive risk model quickly, and enough dedicated engineering capacity that ACS maintenance doesn't compete with core product work

• Highly specific regulatory environments where an issuer's authentication requirements are so unique that no vendor platform fits well without heavy customization

• Strategic differentiation cases where authentication UX is genuinely a core part of the issuer's brand and competitive positioning, not just a compliance checkbox — though even here, most issuers find they can achieve strong UX through configuration on a vendor platform rather than a full custom build

For most issuers, fintechs, and BaaS platforms — particularly those scaling across multiple markets or managing multiple card programs — these conditions don't hold, and the economics tilt clearly toward buying. 

A Practical Framework for Making the Decision 

Before deciding, it's worth asking a few direct questions internally: 

1. Do we have the specialized talent to build and maintain 3DS certification indefinitely, not just for the initial launch? 

2. What's our realistic timeline to a competitive frictionless-approval rate if we start our risk model from zero? 

3. What is the true, fully-loaded cost of a dedicated ACS team over 3–5 years — including certification cycles, security audits, and opportunity cost — compared to a vendor's pricing over the same period? 

4. How quickly do we need to support new authentication methods as they emerge, and can an in-house team keep pace with that roadmap alongside everything else on its plate? 

5. Is authentication infrastructure actually where we want our best engineers spending their time — or is it table stakes we need to get right as efficiently as possible so those engineers can work on what actually differentiates us? 

If the honest answers point toward "this would strain our team and slow our roadmap," that's a build-vs-buy decision that's already been made — it just hasn't been acknowledged yet. 

The Bottom Line 

An in-house ACS isn't just a technical build — it's a permanent operating commitment: certification cycles that never end, a fraud model that has to be trained from scratch, and an operational burden that competes for the same engineering talent your business needs for its actual product roadmap. The costs that show up after year one are usually larger than the costs anyone modeled before year one. 

For most issuers and BaaS platforms, partnering with a specialized, certified ACS provider isn't a compromise — it's the faster, safer, and ultimately cheaper path to strong authentication, freeing internal teams to focus on what actually sets their card programs apart. 

M2P's ACS is built precisely for this: EMVCo and scheme-certified, designed for fast integration into existing issuing and BaaS infrastructure, and backed by a risk engine that benefits from authentication data across a diverse issuer base. If you're weighing build versus buy, it's worth a conversation before the first line of code gets written. 

Want to know what a certified, ready-to-integrate ACS could mean for your authentication approval rates and time-to-market? Get in touch with the M2P team to see it in action.