Tech Talks is a series in which PayPay Group engineers from countries and regions around the world talk about the craft they care about and the challenges they take on. This time, we look at the credit screening system renewal project led by the Systems Division at PayPay Card. The project began with a simple choice: to build it ourselves. Rather than simply replacing a long-running system, it was an effort to redesign the organization so it could design its own future. We spoke with Yasutaka Shiota, Head of the Systems Division, and Jin Okamoto, who led the project, about the design thinking and decisions behind it.
Yasutaka Shiota
Head of Systems Division, Technology Unit
After working on ISP services, he joined Net Trust Co., Ltd., where he was responsible for the development and operation of payment services. In 2013, he transferred to Yahoo Japan Corporation (now LINE Yahoo Corporation), where he served as a Service Manager and Company Security Officer. He later worked at YJ Card (now PayPay Card) and Japan Net Bank (now PayPay Bank), leading the development of security platforms as well as core banking and business systems. Since 2024, he has served as Head of the Systems Division at PayPay Card. Guided by the vision of realizing finance built with an internet mindset, he is driving in-house system development and building the technical foundation that supports continued business growth.
Jin Okamoto
Credit Development Group, Credit & Receivables Development Department, Systems Division, Technology Unit
He has spent most of his career working on business systems, including backend development for credit card screening systems. In addition to system development using Java and AWS, he has been involved in system-wide architecture design, technology selection, API and database design, and a broad range of architecture-related work. He joined PayPay Card in November 2024 because he wanted to take on system development at a larger scale. He is currently working on the credit screening system renewal project, revisiting the design from the ground up, starting with the question of what screening is really supposed to do, and driving the design and implementation of a new architecture.
What the Systems Division Aims to Achieve
Shiota:
The Systems Division covers screening, credit decisions, collections, customer support, data analysis, and internal IT, in other words, the systems that support the card business. We are not a user-facing service. We provide the foundation that keeps the business running. Our role is to keep supporting business growth through technology. As the business grows, the systems that support it have to keep evolving too. To keep delivering new services, the foundation itself has to evolve.
But there was a big obstacle in the way. PayPay Card had several systems that had been in use long before I joined. Of course, those systems are exactly why the company is where it is today. At the same time, as the business moved into its next growth phase, the systems needed to evolve at the same pace. But if a system has become a black box, you have to start by understanding why it works the way it does and how far any change will ripple. So we decided to build it ourselves.
We did not have just one system to tackle. We decided to modernize them one by one, and the first one we chose was the screening system. For a card company, the screening system is the core system that sits at the starting point of card issuance. It was a domain we could not avoid if we wanted to keep supporting growth. We had teammates who understood the business and could translate requirements into clear specifications. We had engineers who could turn those ideas into working systems. I was convinced this team could make it happen, so we kicked off the project.
Okamoto:
When I first heard about the project, my honest reaction was, “This is going to be a tough one” (laughs). But I did not think it was impossible. I was more excited by the possibility that, if we changed this, we could build a future where we kept improving things with our own hands.
Why We Needed to Renew a Long-Running Screening System
Okamoto:
Once the project started, the first thing I did was understand the existing screening system. Before you can design something new, you have to know how the current system actually works. So I went through the whole system piece by piece.
The first thing I noticed was how many systems were connected behind the scenes.
The screening system did not function in isolation. From application intake to screening to result delivery, many systems were involved. Even changing one piece meant checking the impact and coordinating with the teams involved. It was not a system where you could make changes quickly.
As I kept understanding the system, another question started to form: how do we move to a new system step by step? The system had been at the center of the business for many years. Replacing everything at once was not realistic. I started by thinking about how to coexist with the existing system while gradually moving to a new structure.
That same thinking guided our technology choices. We looked at Kafka and gRPC as well, but what mattered most was not adopting the newest technology. What mattered was connecting smoothly with the existing system and being able to migrate step by step. That led us to choose REST APIs.
The architecture we aimed for looked like this. Each service has its own role while working together, so we can improve only what needs to be improved. We wanted a foundation that would let us add new capabilities in the future while keeping the impact as small as possible.
Exploring the Essence of What Screening Really Is
Okamoto:
As I continued to look through the system, I spent a lot of time thinking about one question: What is a screening system really for? At first, I was thinking about how to build a new screening system. But before you design a system, you have to be clear about what that system is responsible for.
When someone applies for a card, there is initial credit screening. There are ongoing credit reviews for existing customers. There are screenings associated with events such as card renewals or customer name changes. As I went through each screening-related process one by one, I realized that what I had originally lumped together as “screening” was actually a collection of very different responsibilities. Even though they were all grouped under the label of “screening,” each one served a different purpose and carried a different responsibility.
As I kept digging, one inconsistency stood out. The process related to credit limit increases existed in another system as well. Why are there two functions doing something so similar? That question led me back to the entire system. As I investigated further, I found cases where old mechanisms that had once been necessary had simply remained in place. At the same time, I found areas where responsibilities that should have belonged to separate systems had never been clearly separated. That was when it hit me: before you split the systems, you have to separate the responsibilities.
Once I started looking at it that way, the architecture began to fall into place. The screening system is responsible for orchestrating the screening workflow. Scoring services focus solely on scoring. Credit bureau integrations are responsible for external data exchanges. Each service owns a single responsibility. Once we structured the system that way, everything became much simpler.
Our technology choices followed the same logic. We were not trying to use the newest technology just for the sake of it. What mattered most was asking, “What is the most natural way to fulfill each responsibility?” Technology was chosen as a result of the design thinking.
Shiota:
I think this discussion was the most memorable part of the project. At first, it was a conversation about renewing a screening system. But at some point, it became a conversation about what screening really is. That led us to define responsibilities more clearly, and the shape of the system naturally followed. What we created was not just a new system. I think it was a way of thinking that would allow us to keep improving things long term.
Choosing Carefully Under Constraints
Shiota:
Once we understood what screening really meant, the full picture started to come into view. But even with a clear design direction, you cannot implement everything at once. This project had originally been planned as a two-year effort. Then we decided to release it in one year. That meant the most important thing was not what to build, but what to do now.
Okamoto:
We were thinking the same way on the ground. Instead of expanding what we could do, we focused on what was truly needed now. That became our decision-making standard. Because we had already defined the responsibilities, we could ask questions like, “Should this be done now?” or “Should this be handled by a different mechanism?” The design thinking itself became the standard for development decisions.
Shiota:
We also chose not to simply rebuild the existing system as it was. It would have been easier to compare, and in the short term it might have been more efficient. But that would have carried the black box forward as well. What we wanted was a foundation we could keep improving. So instead of reproducing old specifications as they were, we kept asking whether each one was truly necessary.
Okamoto:
In the end, we ran the old and new systems in parallel and compared their results one by one. Each time we found a difference, we checked the specifications with the product team and discussed over and over why the results were different.
Some parts had been black boxes, so it took far more time than we expected. But that time is what allowed us to move forward with confidence, one step at a time. Of course, the schedule was not easy. Even so, no one ever said, “We can’t do this.”
Everyone stayed aligned, from the people defining requirements to those designing, building, and testing the system. I never lost the feeling that this team could carry it through to the end.
Shiota:
This release was a milestone, but not the finish line. It felt like we had finally reached the starting line, where we could keep improving things with our own hands.
Toward an Organization That Can Design the Future
Shiota:
What we built in this project was not just one screening system. It was a foundation we could keep improving ourselves. On the business side, there is a desire to make screening possible 24/7, every day of the year.
Right now, screening happens at specific points such as applications or credit limit increases. But in the future, we may be able to make much more flexible, real-time decisions tailored to each user. I think the foundation we built here is the first step toward that future.
Okamoto:
I see this release as just one milestone. With this foundation in place, we can finally take on the next challenge. Even today, many screening decisions are automated, but there are still areas where humans make the call. I want us to keep asking, one question at a time, whether those decisions truly need to be made by a person.
This screening system was built on PayPay Card’s shared AWS foundation. There are still systems that have not moved to that foundation yet. I want to keep spreading the thinking we gained from this project to those systems as well.
Shiota:
AI is already changing software development in a big way. Our team kept trying new tools and constantly updating the way we worked.
The pace of change will only get faster. That is exactly why I want us to stay flexible, keep adopting new technologies, and keep shaping the future with our own hands. That is the kind of organization I want us to be.
