Buy and Build: A New Paradigm for Modernizing Authorization

Hello everyone and welcome to the webinar, Buy and Build, A New Paradigm for Modernizing Authorization. My name is Alejandro Leal. I'm a Senior Analyst at KuppingerCole and today I'm delighted to be joined by Ali and Zulfiqar from Authlete.

Hi, Ali. Hi, Zulfiqar. How are you guys?

Hi, Alejandro. Happy to have you on board and, yeah, I look forward to today's conversation and thank you. And before we begin, I will start with my part of the presentation.

So, for the next 20 minutes, I will set the stage and then Ali and Zulfiqar will join and they will talk about this topic today and then at the end we'll have some time for Q&A. So, feel free to enter any questions at any time and we'll be happy to discuss that after. But before we begin with today's presentation, I would like to remind the audience that all of you are muted centrally so there's no need to mute or unmute yourself.

We will also be conducting a few poll questions during the webinar so it will be great to see you participate in those and we will also be recording the webinar so in the next few days you will see it on our website together with the slide decks. And as I said, please, we're trying to make this interactive conversation so feel free to enter any questions at any time.

So, the agenda for today. As I said, I will be first talking about the case for componentized authorization and then Ali and Zulfiqar will go deeper into this topic.

So, the case for componentized authorization is not a theoretical case. But I think it's a response to the daily reality of development teams. Teams are constantly asked to deliver secure and scalable services at high speed while dealing with legacy identity systems and a lot of compliance demands.

So, in many cases, DevOps teams feel like traditional monolithic authorization stacks can't keep up with today's challenges. So, in this case, in this context, componentized means breaking authorization into smaller parts, standard-based building blocks, you can say, that can be reused, they can be scaled, and integrated through APIs.

So, in a lot of ways, it's about freeing teams from rigid architectures and allowing them to have the freedom to innovate faster while at the same time staying secure. So, it's not about sacrificing control.

Teams, they can maintain consistency and compliance while at the same time, the business can evolve and scale. So, this case is not a luxury or an experiment, but I believe it's a practical response to today's challenges and the constraints that many of these teams face today.

So, it's how modern enterprises can keep pace with change while at the same time preserving trust. And as we know, digital trust is the foundation of today's services.

So, here's the first poll question today. So, what is the biggest obstacle your organization faces in deploying or upgrading SIAM?

So, you will see this question for some time on your screen, and I will be moving forward to the next slide. So, when we talk about SIAM, the first question that often comes up is, what does the C stand for? Is it consumer, is it citizen, or is it customer? And the truth is, as we know, it's all of them. And each of these contexts brings its unique challenges, right?

So, consumers, they might prioritize convenience and speed. Citizens may place a more important focus on privacy and compliance, while customers, they may prefer personalization and engagement.

Yet, in every scenario, we face the same fundamental issue, which is how to manage identity and access securely at scale and across diverse digital environments. So, today, SIAM doesn't exist in isolation anymore. It's also converging with broader security and identity strategies, such as zero-trust architectures, consent orchestration, and in many ways, cryptographic agility, as we prepare for the post-quantum era.

So, what's cool about all of these things is that the complexity of authorization grows. And why? And that's because authorization is where context truly matters.

So, it's not just about verifying who someone is, but it's about understanding what they're allowed to do in a given situation under specific policies and within certain, let's say, regulatory boundaries. So, in other words, authorization is the leading interface between security and user experience. If you get it right, you can enable a seamless, user-friendly, and compliant digital interaction. But if you get it wrong, it can be quite frustrating for users, and it can end up putting your organization at risk.

So, that's why componentized authorization is important for SIAM. It gives organizations the ability to handle this growing complexity in a more structured and modular way. And I'm going to go deeper into that in the next slides.

But first, it's important to know what are the goals of SIAM implementations. So, when organizations today strive to modernize their SIAM, their goals are familiar to us.

You know, they want to replace legacy systems. They want to collect and manage consent. They want to prevent fraud. They want to gain insights through identity analytics. But beneath all of these objectives, I think there's a common foundation, which is authorization.

So, whether you're converting anonymous users into known customers or enabling compliant data collection, you're ultimately deciding what can do what, when, and under which conditions. So, that's why getting authorization right is central to delivering both compliance and a good customer experience. Here in this slide, you see the Kupinger-Cole Identity Fabric. And we often talk about the concept of an identity fabric. And I think this idea is quite relevant for today's discussion.

It's a sort of architectural framework that connects all the building blocks of digital analytics into a coherent whole. So, the identity fabric concept is not based on a single product or a vendor solution, but it's more of a blueprint for how modern identity and access management ecosystems should evolve, given today's challenges. And in this fabric, you can see on the left side, under capabilities, you see that authorization plays a very important role. It's a sort of thread that runs through everything, whether it's IAM, workforce IAM, privilege access, or API security.

And that's why my previous slide on componentized authorization fits perfectly into this model, because it allows each part of the fabric to, in a way, evolve independently, while also maintaining consistent policy and governance across the entire identity ecosystem. In the next slide, you can see the Kupinger-Cole IAM reference architecture. We recently updated this, and we have a very good advisory note that goes deeper into each of these segments.

So, if you are curious about that, feel free to reach out or check our website. So, the reference architecture, it builds on the same philosophy. It's providing a more detailed map.

And here, authorization sits on the right-hand side, and it illustrates its close relationship with authentication, but it has a distinct purpose, as we know. So, authentication answers a question, who are you? Authorization answers, what are you allowed to do? It's a very, let's say, simplified way of looking at this, but as we know, these are two very different things. They're deeply connected, but there are different things in this part of digital trust. Federated authorization, it ties all of this together.

So, it can enable users to access resources across systems or organizations through trust relationships between identity providers and service providers. So, standards like SAML, OAuth, and OpenID Connect are the sort of, the glue that keeps this ecosystem interoperable. In other words, this reference architecture shows that authorization is not a standalone function, but it's a dynamic capability that touches every aspect of identity management, and componentization is what allows it to stay agile as technology and threats and regulations change.

So, authorization is at the center of digital trust, and as I've been saying, it ensures that every access decision is secure, is compliant, and is also context-aware, and as we see today's developments with AI systems and machine identities, and as we move toward this post-quantum readiness, the stakes grow higher, and this is something that Ali and Sufika will probably talk more about, but OAuth and OpenID Connect, they remain the foundational standards, but implementing them at scale can be very difficult. So, these standards are very nuanced.

They require precise handling of protocol flows, scopes, and client registration, and if you look at profiles such as FAPI and client-initiated back-channel authentication, these have even more complexity, especially in high-assurance environments and in industries like finance and healthcare.

So, for many organizations, what they need is not another monolithic SCION platform, but they require a different architectural approach where the core functionalities of authorization standards, such as OAuth and OpenID Connect, these are accessible as programmable components, so as APIs, but when organizations hear about this, in many cases, they have this dilemma. There's this sort of tension between the desire to control, the desire to have that autonomy, but there's also the fear of not knowing how to start.

So, on the one hand, there's this desire for freedom, right, to build modular architectures to select best of breed and to avoid vendor locking, but there's a fear of losing cohesion to becoming more fragmented, fear of integration complexity, and fear of compliance gaps. So, many organizations turn to external solutions, even though they know that they're giving up a measure of control.

So, this can be problematic for them because even small but crucial changes like adjusting consent user experience or modifying client registration flows, it will require support tickets, waiting times, and vendor coordination. So, suddenly, the experience is no longer theirs, but it's mediated by this external solution, and that can lead to some frustration, especially with development teams.

So, this slide also has, it also touches on the relationship between DevOps and, let's say, the business side of things, that there needs to be clear communication on what the team needs to succeed, and business must prioritize that.

So, the real challenge is not simply to build versus buy, but it's about finding a sustainable balance, and in this slide, you will see that the answer is not, let's say, another Scion platform, but what's needed is a hybrid architecture, one that lets you buy proven components for OAuth and OEDC, but build the business logic and the user experience that makes your digital services unique.

So, this way, developers get programmable building blocks instead of just black boxes, and that can accelerate innovation, it can maintain consistency, and it gives them the liberty to decide how they want things to function. So, many organizations struggle with this. They believe that ownership is too complex, that it's far-fetched, that it's not tangible, but it doesn't really necessarily mean to, you know, and at the same time, expert maintained services to handle the complexity around compliance, around security updates.

So, following this logic, organizations can gain the agility to adapt when regulations or business models change. They can ensure consistency in user experience across apps and different regions, and they can maintain control over how consent and policy enforcement are expressed. And I think that's how ownership looks like. It's agile, it's consistent, and it's also governed, and all of these three aspects are working together.

So, when authorization becomes API first, it transforms from, let's say, a constraint into an enabler. So, you can gain configurability and flexibility, better maintenance, and the ability to compose authorization into microservices and applications as needed. And this approach scales naturally. It works with your existing infrastructure instead of replacing it.

And that's why I was alluding earlier to the identity fabric concept, which is about not just rip and replace, but about leveraging what you already have in your identity ecosystem, and you can just scale by adding components that will work for you. So, many organizations would say, okay, so how do I start? And here we have just briefly some steps, some practical guidance, but I know that Ali and Sufikar will go deeper into this, and they will also talk about some case studies. But one step would be to first reassess your SIAM architecture.

So, identify where authorization logic lives today and where it creates bottlenecks. Then you have to prioritize the deployment flexibility.

So, design for modular integration rather than rigid dependencies. Then step three would be to plan for standards evolution.

So, ensure that your architecture can adapt to emerging OAuth and OpenID Connect profiles. And step four will be to build long-term ownership.

So, you have to choose vendors and components that empower your organization instead of boxing them and taking that away from your team. So, the takeaway here is also about not only the communication between organizations and vendors that provide this, but also within your own team. How can you make sure that what your development team needs is going to be consistent and is going to bring value to the business?

So, there needs to be some clear communication as well there. So, with this approach, you can modernize your digital trust architecture without starting from scratch.

And now, I think it's time for Ali and Sufikar to jump in. But before that, one more poll question, which is, which of the following are the main motivations that your organization has for implementing or upgrading SIAM?

So, Ali and Sufikar, the floor is yours. Thank you so much, Alejandro. It's been really insightful, actually, to listen to all your presentations.

Hello, everyone. My name is Ali Adnan. I'm the co-founder of Autly. It's really a pleasure to be here with Kuping or Cole and all of you here. We have quite an amazing audience, consultants, integrators, identity experts, and representatives from banks and large enterprises from a variety of industries.

Today, I'll be speaking about how enterprises are buying to build rather than being caught within a dilemma on whether they must buy or build. So, let's begin with what we stand for at Autly, our super hyper focus on delivering compliance, control, and flexibility. The Autly architecture, first designed by Taka Kawasaki, our co-founder, who also is an active contributor and implementer in enhancing industry best practices, was really designed right from the ground up, all based on open standards to help enterprises strike the right balance between compliance and agility.

In regulated industries like banking and fintech, compliance is non-negotiable, but control and flexibility are also just as critical. The modular approach separates the authorization logic from the authentication system, allowing you to enforce policy while integrating with your chosen identity stack, whether it's built in-house or bought as a service.

So, we look at the build versus buy discussion that has, you know, always been there from the beginning of time. Next slide, please. Okay. When organizations start planning their identity or open finance infrastructure, one of the first strategic questions they face is build or buy. Do we build our own authorization infrastructure from scratch, or do we buy a commercial IAM product? Building internally may sound attractive at first. You get control, you get full alignment, but it comes at a high cost.

You'll need domain specialists to first understand evolving standards, plus ongoing maintenance every time there's an update or there's a rule change. But on the other hand, often leads – but buying, on the other hand, often leads to a monolithic IAM platform that promises to do everything, but at times ends up having you to compromise into their design, and it takes away the flexibility and control.

However, we believe there's a third option, what we called buy and build. You buy the trusted standard compliant authorization engine that handles all the hard parts, like token issuance, consent flows, FAPI compliance, and you build your own experience and authentication layer around it. No lock-in, no duplication of effort, just a clean component that plugs into your architecture through APIs that scales as your ecosystem grows, without worrying about the rigidity of a one-size-fits-all model. Right.

So, where does the Authlete engine sit? A lot of people ask me that, okay, it's light, and it's componentized, but how does it all work?

So, I put this diagram, which later on, Zulfiqar will explain this in further detail, but this diagram really shows where Authlete fits within the modern identity architecture. So, what is Authlete?

Well, Authlete is a Authlete sits just outside the authorization server, acting as the trusted backing component that implements the OAuth2 and the OpenID Connect logic. This separation allows your authorization server to focus on access control and integration, while the component manages the complex standards-driven parts of authorization in a clean, modular way. It's a simple, lightweight, composable architecture, one that lets you own your authentication and authorization layer, your UX, and your data, while the system remains fully compliant.

So, let's take a pause over here. Why Authlete?

Authlete, in essence, is a modular approach that ensures compliance, is cost-effective, scalable, and gives you all the control and flexibility that you want and need to make your system future-proof. Okay, so use cases. This slide highlights the versatility of the modular API-based architecture across different real-world scenarios.

So, because we separate authorization from authentication, this architecture can integrate into almost any digital ecosystem, whether it's a bank modernizing for open finance or a media group managing multi-brand identities, it just works. In financial services, Authlete delivers FAPI 2.0-compliant authorization, enabling secure, regulatory-approved data sharing without needing to replace existing identity platforms.

And for SIs and consultancies, Authlete acts as a reusable authorization layer that accelerates project delivery, so they can integrate faster, stay compliant, and avoid reinventing OAuth and OpenID Connect logic every time. So, whether you're designing for a digital bank, a cross-brand customer platform, this design enables the trusted authorization backbone that adapts to your architecture, not the other way around.

So, let's look at the business benefits. Banks and financial institutions require strong compliance whilst they want to keep control over the UX and data. Fintechs and paytechs need secure, fast authorization without having to build complex infrastructures. Media and digital platforms who manage millions of users across multiple services want to unify authorization. And large enterprises who are thinking to migrate from a monolithic system can now experience flexibility, interoperability, and control.

And, of course, regulated ecosystems such as government need certified, standards-compliant, and vendor-neutral components. So, Authlete serves a multitude of industry and customers, but it's all about this trend where companies are looking at this modular approach across a variety of industries from banks to media companies, sports companies, gaming, and even companies that were looking for a modular solution to secure identities between IoT devices, apps, and partner systems. Let's take a quick example, one from a digital bank and one from a media company.

So, NewBank is now the largest digital bank in the world, having over 122 million customers, and who have adopted this modular architecture to deliver a frictionless, world-class user experience built on trust, simplicity, and security. They implemented the FAPI and SIPA profiles and also introduced this architecture through other services that they provide.

Now, from finance to media, another sector where customer experience and compliance intersect. DPG Media is the largest Dutch-speaking media group, primarily serving the Belgium, Netherlands, and Denmark region. They own newspapers, magazines, radio, and television, who have gone through digital transformation on a large scale, but still having both paper and digital integrated seamlessly.

With Offleet, DPG Media has been able to transform its identity infrastructure from fragmented, brand-specific systems into a unified, more standard-based platform, giving them full control over customer identity and consent. And not only customer identity and consent, but they had full control over the branding, the UX, and you can imagine how challenging that can be when you have to design a system that works seamlessly across multiple services and that have the same look and feel in terms of brand identity.

Now, I'll be handing over to Zulfiqar, who will further explain on the technology and the Offleet architecture that drives this modular approach and how it fits into your identity landscape. On to you, Zulfiqar.

Okay, thank you, Ali. So what is Offleet from a developer perspective? It's a developer-centric OAuth OIDC engine, which gives your developer full control over their authorization solutions while offloading all the complexity of protocol processing and token management to Offleet. We offer extensive support for various OAuth OIDC specifications, including high security profiles like FAPI and CIBA. Offleet offers flexible deployment options depending on your requirements. So if you are a developer, you can quickly get started with our shared cloud service and be up and running within minutes.

For enterprise customers, we offer a dedicated cloud managed service with higher availability and SLAs. We also offer self-managed options for customers who want to run Offleet in their own cloud environment. Offleet is architecture, language, and framework agnostic. So whether you are using .NET, Node.js, or Java, you can integrate Offleet seamlessly in your existing stack. We are developer-centric, but also trusted in production, running highly scalable workloads with thousands of requests per second for multiple years.

And depending on your deployment model, we offer SLA-backed high availability with 24-7 enterprise support and incident response. So in summary, Offleet is developer-centric, but also enterprise-ready. So on this slide, you can see some of the OAuth2 extensions supported by Offleet. So specs like PXE, DPOP, Pushed Authorization, Mutual TLS are just some of the examples of the specs supported by Offleet. You can see the full coverage of all the specs supported by Offleet on our website. Offleet's engagement with specs goes beyond this implementation.

Some of our members are actively participating in various OpenID Foundation working groups, contributing to the definition and evolution of these specs. The Offleet software is used inside the OpenID Foundation certification test suite. So as new specs are created or existing specs evolve, Offleet will be among the first solutions to implement them and certify them. So if you are building on top of Offleet, then you are building on a platform which is built by experts. It's always up-to-date and continuously certified. Let me next show you how Offleet actually works.

As Alejandro and Ali mentioned, we are an API-first service. So all functionalities in Offleet are provided through an API. Our APIs are grouped into two categories. We have management APIs, which is what you use to configure your service. And we have runtime APIs, which you use in your authorization solution to offload protocol processing and token management to Offleet. On top of these APIs, we have built some additional services, like our management console, our Terraform provider, and various SDKs which you can use to build custom authorization solutions.

Because it's the same underlying API, there is no runtime or SDK lock-in. If you like our SDKs or if you like our console, you can use that. And if that does not fit your workflow, you can call the APIs directly. We have detailed documentation on our website, including an API explorer, which you can use to test our APIs directly from the browser.

Next, let me show you how Offleet fits into your system architecture. And as Ali mentioned, we are a back-end service which sits behind your API infrastructure and takes care of all the heavy lifting of protocol processing and token management. Your API clients and your user don't interact with Offleet directly.

Instead, they talk to your own API infrastructure. And your API infrastructure then calls Offleet whenever it needs to handle OAuth or OIDC requests or when it needs to perform token validation. So in summary, your API infrastructure is in full control of the user experience. You don't need to change how your user authentication works, how your API gateway functions. Offleet just augments your API infrastructure and takes care of OAuth, OIDC functionalities.

Now, let me drill down a little bit and show you how this works at the protocol level. So here we can see a sequence diagram, which is showing an authorization request with operation code flow landing on your OAuth, OIDC server. As you can see, your OAuth, OIDC server can simply forward this authorization request as is to Offleet. If you look at it carefully, you will see that the parameters passed to Offleet API are exactly the same parameter as received on the original request. That means your OAuth, OIDC server does not need to implement any complex logic.

It can simply proxy the request to Offleet and Offleet will take care of all the heavy lifting of protocol processing. Once Offleet has successfully validated the request, it can guide your OAuth, OIDC server about the next steps in the authorization process. So in this case, we can see that the Offleet is returning interaction response, which means that the OAuth, OIDC server should perform user authentication and the consent processes. Once those processes are completed, your OAuth, OIDC server can make another API call to Offleet to resume that authorization process.

And at the end of that, Offleet will issue an authorization code back to your client. And at this point, the client can follow exactly the same model and make the OAuth token request to your OAuth, OIDC server.

Again, your OAuth, OIDC server can simply proxy that call to Offleet, where Offleet will validate all the protocol parameters as well as validate the authorization code. And if all looks good, it can issue a token response containing your access token, your refresh token back to your client. So once your client has access token, it can then use that token to call a protected API.

So again, that same core pattern applies here. Instead of your resource server implementing complex token validation logic, it can simply forward that token to Offleet introspection endpoint. And Offleet will now validate the token and return the response back to your resource server. So the takeaway here is that your OAuth, OIDC server can keep full control of the user experience and it can delegate the protocol request to Offleet as is.

Similarly, your resource server can focus on its own business logic and all the token validation complexity can be offloaded to Offleet. Now, let's take a step back and see how Offleet fits into your wider enterprise architecture. So as you can see here, Offleet is a component focused on protocol processing and token management. It works alongside with your IAM stack and your API gateway. One thing to note here is that there is no direct connection between Offleet and your IAM system. And that means all of your user data and your user credentials are completely isolated.

This design makes it much easier and safer to deploy Offleet in existing enterprise architectures. This also means that Offleet can work with any IAM system, whether it's an in-house system or a third-party service.

Similarly, we can integrate with any API gateway and offload the token validation responsibility to Offleet. So in summary, you can deploy Offleet in your existing enterprise architecture. To modernize your OAuth, OIDC functionalities without changing your IAM stack or without changing your API gateway. So here you can see some more references. If you want to learn more about Offleet, you can sign up for a free trial on our website. And please feel free to reach out to us if you have any questions. I'll hand it over to Alejandro for question answers.

Thank you, Sothekar. Thank you, Ali, for a very informative presentation. I know there are already some questions in the Q&A, but before that, I will just quickly go over some of the related research that you guys can go and take a look to get more information on the topic. Ali had a very interesting EIC session, I believe it was last year, on building your own authorization server. So you can look for that and watch it. And a reminder that, again, we will have the European Identity and Cloud Conference next year in Berlin. It will be taking place in May.

And this year, we'll have the Identity-Centric Cybersecurity event in November in Frankfurt. And just quickly, you can find more information on our membership program by going to our website.

And yeah, that's all about marketing, let's say. Now we can go and take a look at the questions. I know that Ali already replied to one of them, but maybe we can talk about it again. So one of the users asked, what are some of the functionalities you offer through your console?

And maybe, Ali, you can take that one. Yeah, I think you all can take that one.

Yeah, so Alejandro, as I mentioned earlier, Outleet is an API-first solution. So all the functionalities of Outleet are available through APIs. But we have obviously built additional services on top of those APIs. And one of those services is our console. So you can actually fully configure your service using our console. You can log in into that console using various different forms of authentication methods.

So initially, we only offered very simple authentication mechanisms to log in into the But as our solution is used by more and more enterprises, we learned that we need to support federated authentication for our console. We need to support multi-factor authentication. So all of those capabilities are now added in our console. So it's a secure application which you can log in. And then you can use that to configure all aspects of your OAuth OIDC service.

OK, that makes sense. There's more questions in the chat, and I would like to address those. Patrick here is asking, could you please provide examples on how you support developers at implementing authorization? And there was also another question related to that one on if you provide some sort of documentation or developer onboarding.

Yes, we have detailed documentation available on our website. We have samples and reference implementation also available where developers can quickly see how OPLIT is used in that reference implementation. So on our GitHub page, you will find a Java OAuth server, which is a reference implementation of how to integrate OPLIT in your OAuth OIDC server. And I think that will be the best resource to start with. In terms of helping developers, we also offer advice and guidance.

If a developer wants to reach out to us, I think we will be happy to provide advice and guidance to unblock them and help them integrate OPLIT in their solutions. Do you sometimes get questions from developers that they don't always have the support, let's say, from the business team? And is that something that you've had conversations around that? Like they tell you, OK, you know, this sounds great, but we need to convince the people making the decisions that this is going to be good for us. I'm not sure I understood the question, so maybe Alejandro, you can rephrase it.

Yeah, so I'm asking if when you talk to some of your clients, since it's a very developer focused solution, do they tell you that they struggle to communicate with the executive team, the people making the decision whether the solution is going to be adopted or not? Because as I mentioned briefly in my presentation, I think it was one of the answers in the poll question that there is always this IT versus business conflict. And I'm wondering if that's the case in your conversations.

Yeah, yeah, absolutely. I think we, to be very honest with you, we have not heard of that kind of friction too much here. And I think the reason is because OPLIT has a very low footprint when it goes into your enterprise environment, like we talked about earlier. It's just a component which fits into your existing enterprise architecture. So in fact, I remember, I can now recall some examples where, you know, you don't even need to involve your corporate IT service if you are just modernizing the OAuth, OIDC functionality for your APIs. Even a business service can do that on its own.

So because OPLIT offers this modular architecture which fits in with your existing IAM system, with your existing API gateways, generally there is less pushback and resistance in terms of deploying OPLIT in that bigger enterprise architecture. And maybe that is one of the reasons we have not seen many examples where developers want to adopt OPLIT, but the IT and the wider enterprise is against that idea.

Yeah, I see. That makes sense. There's another question that Ali already addressed in the chat, but maybe we can also touch on that. So the question is, you talked about some customer examples in your presentation. What are some of the trends that you see among your customers?

Yeah, so we are definitely seeing a trend where customers are looking for a componentized approach because they feel like going through, you know, it's again that build or buy kind of a discussion, right? Where they feel like customers who want to build it themselves feel like if they can get a component from a highly specialized group of domain experts, then they feel comfortable in building their own. That kind of empowers them to build their own.

Another trend that we're seeing is that a lot of the banks around the world, especially when regulators are mandating and, you know, promoting open banking and open finance, regulators are beginning to mandate some of the security profiles, and one of them is FAPI. And so especially banks who need to comply to regulatory mandates need to comply with FAPI, and they're looking for partners that can help them, you know, support FAPI in a very lightweight, very compliant, and in a very quick way.

Okay, perfect. We have one more question, and then we will look at the polls. The last question is, you mentioned Outlet is highly scalable. Is there any scalability limit for your service?

Yeah, I can take that. So yes, as I mentioned earlier, I think we are running thousands of RPS in production for multiple years now. We have customers who are using our dedicated cloud managed service, and they are doing thousands of RPS requests per second on that service. In addition to that, we have successfully tested our service with up to 50,000 RPS. And we believe that's a huge number, way beyond any other service out there supports.

Okay, awesome. All right, so now it's time to look at the questions, and maybe we can have a brief discussion before we wrap it up. I'm not sure if the people can see the poll question results, but the first question was, what is the biggest obstacle your organization faces in deploying or upgrading SIAM? And it looks like it's a tie between two options. One is legacy app integration, and the other one is business versus IT alignment on goals. There's also, I think the third one, very close was scalability. So it matches well with your previous question and answer.

And the last poll question, which of the following are the main motivations that your organization has for implementing or upgrading SIAM? It looks like number one, 57% is to improve security, and the second option with almost 30% to improve the consumer slash customer experience. What do you think about that? Do you see also that security versus user experience a lot? Yeah.

Yes, there's always that balance that customers want to strike, and so it's not just about security, but it's also about the user experience, for sure. Yeah, especially in SIAM. Yeah. All right.

Yeah, that's all from our side. I would like to thank you again for joining me today. I think it was a very fruitful conversation, and it's a very relevant topic that I think will continue to gain more momentum. So thank you again for joining me.

And again, if any of the audience members has a question or any comment, feel free to reach out to Ali and Sulfikar or go to Outleet's website for more information. Thank you. Thank you.