The Hardest Part of Modernizing Your Card System Isn't the Technology

A Conversation with Archer Zhang, COO of QCC  | CLPS Technology (NASDAQ: CLPS)

Editor's Note

I've spent over three decades in the payments industry — from the floors of Bank of China in 1988 to building cross-border payment infrastructure for some of the earliest e-commerce platforms in China, to my years working closely with IBM mainframe-based card processing systems at the heart of global payment infrastructure.

In that time, I've watched many card system modernization projects. Some succeeded. Many didn't. And when they failed, the reason was almost never the technology.

It was always the same thing: organizations that successfully deployed a new platform but never actually changed how they thought about the business underneath it. New system, old mental models. The technical migration was complete; the cognitive migration never happened.

That's what I wanted to explore with Archer Zhang.

Archer is the COO of QCC (Qinson Credit Card Services Limited), the company behind CAKU — a next-generation card issuance platform and wholly-owned subsidiary of CLPS Technology (NASDAQ: CLPS). Before that, he served as China CIO at a leading global card processing company, meaning he spent years running the very type of system that CAKU is now designed to replace.

That background makes him one of the few people in this industry who has seen both sides of this transition firsthand. He understands why the old world worked. He also understands, with unusual precision, why it can no longer be enough.

This conversation covers the architecture of CAKU, the realities of legacy migration, where the boundary between card issuance and digital wallets is heading, how QCC competes against established global players, and — the question I most wanted to ask — what it actually takes for a bank to let go of thirty years of institutional habit.

The answer, as Archer put it, is this:

"The hardest part isn't the migration. It's the forgetting."

— Kevin Piao, Co-founder, ChainTech

Part One: The End of an Era

Kevin: You spent years as CIO of one of the world's largest card processing platforms — an IBM mainframe-based system that served hundreds of millions of cards globally. How do you define what that era represents, and why is it ending?

Archer: That generation of IBM mainframe-based systems wasn't just a piece of software — it was the product of an entire era of financial infrastructure thinking. Since 1996, it has processed cards for hundreds of banks globally, and at its peak, served over 600 million cards. That track record is real. That stability is real.

But that generation of systems represents a paradigm I'd describe as: the system defines the business. Banks first defined their card products, then fit customers into those products. The technology dictated what was possible, and business teams worked within those constraints. That was appropriate for its time — in the mainframe era, stability and predictability were everything.

What's changed is that the market now moves faster than that paradigm allows. Customer expectations change in months, not years. New payment methods emerge constantly. Banks can no longer afford to wait six months for a vendor's development cycle before launching a new product.

Kevin: So how does CAKU redefine the paradigm?

Archer: The inversion is fundamental: the business defines the system, not the other way around.

There are four specific shifts that make this concrete.

The first is the data subject. Traditional systems are product-centric — you design a product, then attach customers to it. CAKU is customer-centric — the customer is the primary data unit, and products are simply tools the customer uses. This single change affects how limits, billing cycles, interest calculations, and reporting are designed at the foundational level.

The second is the processing paradigm. Legacy systems are batch-processing at their core — real-time capabilities were bolted on afterward. CAKU is real-time first: real-time posting, real-time credit limit recovery, real-time risk controls. Batch processing becomes one output method, not the primary architecture.

The third is the system boundary. Legacy IBM mainframe-based systems are closed, self-contained fortresses. CAKU is a platform — it defines a core capability set, but through 1,200+ APIs and modular assembly, it returns extensibility to the client. The system doesn't try to do everything; it gives clients the capability to build what they need.

The fourth is the operational philosophy. Legacy systems were designed to prevent failure. CAKU is designed to recover from failure fast, invisibly to the end user. That's not a subtle distinction — it changes how you build, test, and deploy everything.

Kevin: And what does moving to cloud actually change — beyond just where the system runs?

Archer: This is where I think most people underestimate what's really happening. Moving to cloud isn't changing the address where your system lives. It's changing the fundamental relationship between a bank and its own risk tolerance.

Let me give you a concrete example. In the legacy world, releasing a new version of your card platform meant a full cutover — every customer, all at once, with no easy way back. The consequence of that architecture was that banks would release two, maybe three times a year, and every release was an event surrounded by anxiety.

On CAKU's cloud-native architecture, you can release to one percent of traffic, observe, expand gradually, and roll back in seconds if anything looks wrong. The blast radius of any problem shrinks to nearly zero.

Here's the number that I think captures the shift most clearly, in Archer's own words:

"Before, banks dared to release twice a year. Now they can release twice a week — and it's actually safer."

That's not an incremental improvement. It's a different relationship with innovation entirely. Banks that previously had to agonize over every feature decision can now experiment, learn, and iterate at the speed of their market.

Cloud also enables geographic distribution with compliance intact — the same platform architecture can be deployed across multiple jurisdictions, with data residency maintained locally while logic is managed centrally. For Southeast Asian banks operating across fragmented regulatory environments, this matters enormously.

Part Two: When the Walls Come Down

Kevin: QCC announced the integration of stablecoin settlement into CAKU in late 2025 — USDC and USDT for repayments, POS settlement, and credit limit management. That feels like a significant line being crossed. From a product perspective, does the boundary between card issuance and digital wallets still need to exist?

Archer: Technically, that boundary has already become optional. Commercially and regulatorily, it still exists in most markets — but the nature of it has changed fundamentally.

Here's how I think about it. Traditionally, card issuance handled balance management, authorization, billing, and settlement. Digital wallets handled top-ups, P2P transfers, and QR payments. These were separate systems because they were built by different teams, for different purposes, in different regulatory contexts.

What CAKU's architecture allows now is a single account structure that can manage both simultaneously. A customer's credit limit, their stablecoin balance, their rewards points — these can all operate within one coherent system. The boundary, where it still exists, is a regulatory and commercial choice. It is no longer a technical constraint.

Kevin: Can you walk through what that actually looks like for a real user?

Archer: Think about a user in Southeast Asia today. They open their mobile banking app, make a payment by QR code, repay their balance in USDC, and redeem points to offset their next transaction. That entire chain — authorization, settlement, digital asset handling, rewards management — can now run on a single platform.

The stablecoin integration isn't a separate module we bolted on. It runs through the same authorization engine, the same limit management, the same clearing logic. We treat it as another instrument type — the same way we handle Visa, Mastercard, UnionPay, Apple Pay, and virtual cards.

Kevin: How do you define CAKU's position in this context? Is it a card platform that added stablecoin support, or something broader?

Archer: I'd put it this way: CAKU is a payments engine. The card is one plug-in.

Legacy card systems were designed around the physical card — card number, expiry date, CVV, EMV chip, network messages. Payment was an output of the card system.

We inverted that. CAKU starts with the payments engine — how a transaction gets processed, how limits are managed, how the ledger is updated, how risk is evaluated, how settlement is calculated. The card is simply one interface that calls that engine. So are Apple Pay tokens, QR codes, virtual card numbers, biometrics, and stablecoin wallets.

This isn't a future aspiration. It's the current architecture. What determines the deployment of any specific interface is market readiness and regulatory context — not our system's capability.

Part Three: The Realities of Migration

Kevin: Before we go further, I want to go back to something foundational. You've talked about what CAKU can do. But the harder question for most banks is getting from where they are to where they want to be. What does a real migration actually look like, and where do projects go wrong?

Archer: Most people underestimate migration because they frame it as a technology problem. It isn't. It's a knowledge problem first, and an organizational problem second. The technology is usually the most straightforward part.

Let me start with how we actually begin a migration engagement.

The first step isn't touching any code. It's building what we call a KYS document — Know Your System. Before we can help a client move off their legacy platform, we need to read that platform completely: every business rule, every data flow, every interface dependency, every exception handling path.

Kevin: Why is that necessary? Don't banks know their own systems?

Archer: This is the most important thing I can tell anyone considering a migration: most banks do not fully know their own systems.

Here's the most common example. Interest calculation logic in a legacy system may have been modified seven or eight times over the decades — once for a promotional campaign, once because of a regulatory rounding requirement, once for a specific product type that no longer exists. The people who made those changes have largely left the organization. The documentation was never updated. The code comments are wrong.

The result: no one in the bank can definitively explain how interest is currently calculated in production.

After completing a KYS exercise, clients consistently discover that roughly 30% of their existing business rules haven't been touched in over three years. Some are genuinely obsolete. Some reflect products that were discontinued. Some are legacy patches for issues that no longer exist.

That discovery changes everything about the migration strategy.

Kevin: Once you've completed the KYS exercise, what paths are available?

Archer: Clients face three choices.

The conservative path is language replacement only — we use the KYS document to generate equivalent Java code. The platform changes; the business logic stays almost identical. New bottle, old wine.

The progressive path is migrating to CAKU's architecture. The KYS document becomes the migration checklist — which rules to carry forward, which to optimize, which to retire.

The recommended path — and the one most clients choose once they've seen their KYS results — is to treat the KYS findings as a design brief for rebuilding the business logic properly, rather than migrating all of it blindly. When clients see that a third of their rules are dead weight, they stop asking "how do we move everything" and start asking "what should we actually be building."

Kevin: What are the most common failure points in migration projects?

Archer: Three, consistently.

The first is data quality. This is the most common, the most hidden, and the most lethal — and in most cases, the client doesn't know the problem exists. Dirty data has coexisted peacefully with legacy systems for decades because the old platform's validation rules were loose. When you move that data into a modern system with strict validation, everything surfaces at once.

The remedy is a full data quality assessment before migration begins. Every issue classified by severity. A joint decision with the client on what must be fixed before migration, what can be handled by exception rules in the new system, and what can be accepted as historical record.

Kevin: What's the second?

Archer: Implicit business rules — logic that lives in the code but has never been documented. This is related to the interest calculation problem I described earlier, but it's broader. Rules that only trigger under specific combinations of conditions. Edge cases that were handled ad-hoc twenty years ago and became permanent fixtures.

Our approach is to use the digital twin mechanism as a discovery tool. We run new and old systems in parallel on the same historical transaction data, comparing results field by field. Every discrepancy is a clue to an undocumented rule. This reverse-engineering methodology is more reliable than reading code or interviewing staff — and our team has developed tooling specifically for this over multiple engagements.

Kevin: And the third failure point?

Archer: Scope instability — clients cycling between "migrate everything" and "go live quickly" throughout the project.

Banks often begin with a complete migration mandate: every feature, every data record, every piece of history. When that proves unworkable, the pendulum swings to aggressive scope cuts. Then back again when stakeholders raise concerns. Projects that oscillate between these poles consistently go over time and over budget.

Our discipline is to force a three-tier prioritization at project initiation: Must Have — without this, the business cannot operate; Better Have — strongly recommended but temporarily acceptable to defer; Nice to Have — additive improvements. That line must be drawn on day one and protected throughout.

Part Four: What CAKU Deliberately Doesn't Do

Kevin: I want to ask about product philosophy. CAKU has over 1,200 APIs and supports what sounds like a comprehensive capability set. But I've noticed the press materials are also specific about what CAKU doesn't do. Can you talk about those deliberate choices?

Archer: The boundaries we don't cross are as important as the capabilities we've built. We made four deliberate decisions to stay out of adjacent domains.

We don't build reporting tools. Client reporting requirements vary too dramatically for us to build something genuinely good for everyone. We provide standard reports and clean data interfaces — then let clients use the BI tools they already know, whether that's Tableau, Power BI, or something else.

We don't build a workflow engine. Every organization's internal approval flows, dispute handling paths, and operational procedures are different. We provide embeddable process nodes that plug into existing BPM systems rather than trying to replace them.

We don't build a front-end UI framework. CAKU provides backend capability. What the teller screen looks like, what the mobile banking interface looks like — that's the client's design decision, not ours.

We don't build a data lake. We produce clean transaction data that feeds into clients' analytics platforms. Building and maintaining a data lake is a distinct competency; we don't pretend it's ours.

The underlying principle: CAKU owns the core card processing domain — accounts, transactions, limits, ledger, clearing. Everything outside that domain, we open through APIs and let specialists handle.

This isn't false modesty. It's how we stay excellent at what we're actually for.

Kevin: Where do the parameters run out? What happens when a client's requirements exceed what configuration can handle?

Archer: Parameters have three natural limits.

The first is non-linear cross-parameter logic — when two parameters combine to produce unexpected behavior, the combinatorial complexity exceeds what a parameter system can resolve. We handle this through a scenario rules engine: parameters define static dimensions, the rules engine manages dynamic combinations.

The second is process-level divergence. Some clients' approval workflows or dispute resolution paths are different enough from our standard design that no parameter can bridge the gap. For those cases, we provide modular process components that can be assembled within their existing BPM environment.

The third is genuine innovation — features that don't yet exist anywhere. When a client wants something the market hasn't built, the parameter doesn't exist. Our protocol is to implement it in code first, validate the business logic, then abstract it into a parameter or component for future use.

When a requirement falls outside parameters, we ask three questions before deciding how to respond: Is this specific to one client, or is it a market pattern? Will the client pay for the differentiation? Is this likely to become an industry standard? The answers determine whether we build a code extension, a parameter extension, or tell the client their requirement isn't viable.

Part Five: Competing Against the Giants

Kevin: Let's talk about the competitive landscape directly. In Southeast Asia, QCC is competing against established global platforms with decades of brand equity, global reference networks, and significantly larger implementation footprints. How does CAKU win deals in that environment?

Archer: I'll start with the honest answer: in brand recognition and ecosystem breadth, we don't match them. That's simply true.

Where we compete is more specific.

Depth in card processing. Most established global platforms are fundamentally core banking systems; card processing is one module within a much larger product. Others originated in lending and have built card capability more recently.

CAKU was designed, from the first line of code, exclusively for card issuance. In complex credit limit structures, multi-tier account hierarchies, and network-specific processing rules, the depth is different. Clients who need a card as their primary capability, not an add-on, notice this.

Total cost of ownership. The global platforms carry significant pricing premiums that reflect their brand equity and channel structures. CAKU's TCO is significantly lower — not because of technical inferiority, but because we don't have the same overhead structure. For price-sensitive regional banks in Southeast Asia, this is a genuine differentiator.

Local responsiveness. We have on-the-ground teams in Singapore, the Philippines, Indonesia, and Malaysia. Four-hour on-site support is possible. The global platforms' Asia-Pacific support tends to be concentrated in a small number of hubs, with response times that reflect it.

Legacy migration expertise. We have a dedicated practice for IBM mainframe-based card platform migration, with proprietary tooling and accumulated experience in data model mapping and business rule translation. Competitors can support migration, but typically through partner networks with variable quality and timelines.

Fit for mid-tier clients. The global platforms' commercial strategies are oriented toward Tier 1 institutions. Mid-sized regional banks in Southeast Asia are not their priority segment. They are ours.

Kevin: How do you think about the digital twin capability specifically, given that established players use similar language?

Archer: The language is similar. The implementation depth is where it diverges.

Our digital twin works in two distinct modes. The first is test environment parallel running — both systems process identical historical transaction data simultaneously, results compared field by field. This resolves correctness questions: does the new system produce the right outputs?

The second is production environment parallel running — both systems process live transactions simultaneously, with CAKU operating in shadow mode and its results withheld from customers. This resolves confidence questions: does the bank dare to cut over?

Most competitors offer the first mode. We've operationalized both in live client engagements. The distinction matters because the second mode eliminates the most significant source of migration anxiety — the fear that you'll only discover problems after you've already committed.

Part Six: The Hardest Part

Kevin: I want to return to something you said at the start of this conversation — that the hardest part isn't the migration, it's the forgetting. What does that actually mean in practice?

Archer: Let me describe what we encounter on almost every implementation.

The bank has agreed to move to CAKU. The contract is signed. The project has started. And then, in the early design workshops, we start explaining that CAKU is customer-centric rather than product-centric — that limits aren't attached to products, they're attached to customers; that reporting isn't structured by product line but by customer profile.

And the response from the bank's team isn't resistance, exactly. It's confusion. Genuine confusion.

"If parameters aren't attached to products, how do we maintain them?"

"If limits aren't segmented by product, won't customers misuse their available credit?"

"Our reporting workflows are built around product categories. How does that work here?"

These aren't bad questions. They're the right questions asked from the wrong mental model. The people asking them are experienced professionals. They're not resisting change. They're working from a framework that was correct for thirty years and is now no longer the right frame.

Kevin: How do you bridge that gap?

Archer: The first thing I tell implementation teams is: your job isn't to teach people how to use CAKU. Your job is to help them unlearn the assumptions that make CAKU seem strange.

The product-centric mental model isn't just a workflow habit — it's structural. It shapes how people define requirements, how they write specifications, how they think about customer behavior. When we ask clients to think customer-centrically, we're asking them to rebuild a cognitive framework that has been reinforced by every tool, report, and meeting they've had for their entire careers.

This is why, in our experience, the clients who succeed fastest aren't necessarily the most technically sophisticated. They're the ones with leadership that explicitly creates permission to question old assumptions — where someone senior enough says out loud: we are going to rethink how we do this, not just move the same logic to a new platform.

Kevin: And the clients who struggle?

Archer: The ones who struggle almost always share one characteristic: they define the migration as a technology project rather than a business transformation. They assign it to their IT department, set a go-live date, and expect to emerge on the other side with a better system running the same operations.

That can work, technically. But they've missed the opportunity that the migration creates — the chance to actually redesign the business logic with the benefit of thirty years of learning and modern tools. They migrate the 30% of rules that haven't been touched in three years right along with everything else.

The banks that use this moment well treat the migration as a forcing function. They take the KYS findings seriously. They ask: of everything we're currently doing, what would we actually design this way if we were starting fresh today? And they use the migration to implement the answer.

Kevin: One last question. If you had to explain to someone completely outside the industry what CAKU does — one sentence, no jargon — what would you say?

Archer: A ready-to-deploy API stack that lets you add card issuance, payments, loyalty, and billing to your application.

Closing Note

There's a principle in martial arts traditions — the idea that true mastery arrives not when you've memorized every technique, but when you've internalized the underlying principles so completely that the techniques themselves become unnecessary. You stop thinking about what move to make and simply respond.

The banks that will succeed in the next phase of card issuance modernization aren't necessarily the ones with the largest technology budgets or the most aggressive migration timelines. They're the ones willing to do the harder work: questioning the assumptions that made sense in 2005 and deciding which still apply.

Migrating the system is the visible part. Forgetting what you no longer need — that's the actual work.

About QCC

Qinson Credit Card Services Limited (QCC) is a wholly owned subsidiary of CLPS Technology Inc. (NASDAQ: CLPS) and provides modular, API-driven payment and financial infrastructure solutions to banks, fintech companies, and regulated financial institutions worldwide.

This interview has been edited for length and clarity. All quotes were reviewed and approved by Archer Zhang prior to publication.