{"id":27779,"date":"2026-09-10T12:54:18","date_gmt":"2026-09-10T07:24:18","guid":{"rendered":"https:\/\/blog.razorpay.in\/blog\/?p=27779"},"modified":"2026-09-10T18:00:43","modified_gmt":"2026-09-10T12:30:43","slug":"vulcan-how-razorpay-built-a-foundation-model-for-payment-decisions","status":"publish","type":"post","link":"https:\/\/razorpay.com\/blog\/vulcan-how-razorpay-built-a-foundation-model-for-payment-decisions\/","title":{"rendered":"Vulcan: How Razorpay built a foundation model for payment decisions"},"content":{"rendered":"<p class=\"lead-in\">Anyone who has bought something online has been through this journey.<\/p>\n<figure class=\"fig\">\n<div class=\"analysis-figure pj\">\n<figure id=\"attachment_27781\" aria-describedby=\"caption-attachment-27781\" style=\"width: 1486px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-27781 size-full\" src=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.11.12-PM.png\" alt=\"\" width=\"1486\" height=\"370\" srcset=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.11.12-PM.png 1486w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.11.12-PM-300x75.png 300w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.11.12-PM-1024x255.png 1024w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.11.12-PM-768x191.png 768w\" sizes=\"auto, (max-width: 1486px) 100vw, 1486px\" \/><figcaption id=\"caption-attachment-27781\" class=\"wp-caption-text\">The shopper\u2019s view of one online payment: six ordinary steps from cart to doorstep. Everything else happens out of sight, in the seconds between paying and seeing the confirmation.<\/figcaption><\/figure>\n<\/div>\n<div>\n<p class=\"standfirst\">To a shopper, a payment is one action: choose a method and click Pay. Behind that action, we have to get many decisions right, from the moment checkout renders to long after the parcel ships. Four of the most consequential:<\/p>\n<ul class=\"standfirst-list\">\n<li><strong>Routing<\/strong>\u00a0is real time: the decision to send a payment down the right path must be made with low latency, while the shopper waits.<\/li>\n<li><strong>Fraud<\/strong>\u00a0is distributed: the decision to block a payment must be made from evidence spread across merchants who cannot see each other, with confirmation arriving weeks later.<\/li>\n<li><strong>Delivery risk<\/strong>\u00a0is anticipatory: the decision to offer cash on delivery must be made at checkout, before the payment or the delivery outcome exists.<\/li>\n<li><strong>Checkout ordering<\/strong>\u00a0is silent: the decision to show one method first must be made as the page renders, with feedback that never says why a shopper left.<\/li>\n<\/ul>\n<figure class=\"fig\">\n<div class=\"analysis-figure pj\">\n<figure id=\"attachment_27782\" aria-describedby=\"caption-attachment-27782\" style=\"width: 1638px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-27782 size-full\" src=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.12.03-PM.png\" alt=\"\" width=\"1638\" height=\"718\" srcset=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.12.03-PM.png 1638w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.12.03-PM-300x132.png 300w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.12.03-PM-1024x449.png 1024w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.12.03-PM-768x337.png 768w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.12.03-PM-1536x673.png 1536w\" sizes=\"auto, (max-width: 1638px) 100vw, 1638px\" \/><figcaption id=\"caption-attachment-27782\" class=\"wp-caption-text\">The hidden work inside the same journey, each decision placed under the step where it is made. Every call happens inside a crowded system. One payment can cross a gateway, a card network or the UPI switch and two banks within seconds, in an ecosystem that clears millions of digital transactions a year. These four are the most consequential of the many decisions we make along the way; none is visible to the shopper.<\/figcaption><\/figure>\n<\/div>\n<\/figure>\n<div>\n<p class=\"standfirst\">For years, each decision had its own machine learning model and its own view of a payment. That approach worked, but the learning stayed inside each model. <strong>Vulcan is Razorpay&#8217;s payments foundation model.<\/strong> Its reusable core, called the backbone, learns patterns common to payments; task-specific context and decision layers use that learning to answer particular questions. This article explains why we built Vulcan this way, how the four decisions differ, and what a shared foundation gives us that separate models could not.<\/p>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_80 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Table of Contents<\/p>\n<label for=\"ez-toc-cssicon-toggle-item-6aa2cfb958e20\" class=\"ez-toc-cssicon-toggle-label\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/label><input type=\"checkbox\"  id=\"ez-toc-cssicon-toggle-item-6aa2cfb958e20\"  aria-label=\"Toggle\" \/><nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/razorpay.com\/blog\/vulcan-how-razorpay-built-a-foundation-model-for-payment-decisions\/#One_purchase_four_decisions\" >One purchase, four decisions<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/razorpay.com\/blog\/vulcan-how-razorpay-built-a-foundation-model-for-payment-decisions\/#Vulcans_backbone\" >Vulcan&#8217;s backbone<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/razorpay.com\/blog\/vulcan-how-razorpay-built-a-foundation-model-for-payment-decisions\/#How_Vulcan_learns_reusable_payment_patterns\" >How Vulcan learns reusable payment patterns<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/razorpay.com\/blog\/vulcan-how-razorpay-built-a-foundation-model-for-payment-decisions\/#How_routing_combines_durable_knowledge_with_recent_state\" >How routing combines durable knowledge with recent state<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/razorpay.com\/blog\/vulcan-how-razorpay-built-a-foundation-model-for-payment-decisions\/#Question_one_which_route_will_succeed\" >Question one: which route will succeed?<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/razorpay.com\/blog\/vulcan-how-razorpay-built-a-foundation-model-for-payment-decisions\/#What_does_%E2%80%9Cfailure%E2%80%9D_actually_mean\" >What does &#8220;failure&#8221; actually mean?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/razorpay.com\/blog\/vulcan-how-razorpay-built-a-foundation-model-for-payment-decisions\/#What_a_route_actually_is\" >What a route actually is<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/razorpay.com\/blog\/vulcan-how-razorpay-built-a-foundation-model-for-payment-decisions\/#Why_rules_and_retries_run_out\" >Why rules and retries run out<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/razorpay.com\/blog\/vulcan-how-razorpay-built-a-foundation-model-for-payment-decisions\/#Question_two_is_this_fraud\" >Question two: is this fraud?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/razorpay.com\/blog\/vulcan-how-razorpay-built-a-foundation-model-for-payment-decisions\/#Question_three_will_this_parcel_come_back\" >Question three: will this parcel come back?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/razorpay.com\/blog\/vulcan-how-razorpay-built-a-foundation-model-for-payment-decisions\/#Question_four_which_method_does_this_shopper_want\" >Question four: which method does this shopper want?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-12\" href=\"https:\/\/razorpay.com\/blog\/vulcan-how-razorpay-built-a-foundation-model-for-payment-decisions\/#Why_sharing_matters\" >Why sharing matters<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-13\" href=\"https:\/\/razorpay.com\/blog\/vulcan-how-razorpay-built-a-foundation-model-for-payment-decisions\/#What_we_can_see_across_the_network\" >What we can see across the network<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-14\" href=\"https:\/\/razorpay.com\/blog\/vulcan-how-razorpay-built-a-foundation-model-for-payment-decisions\/#Why_Indias_payment_variety_matters\" >Why India&#8217;s payment variety matters<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-15\" href=\"https:\/\/razorpay.com\/blog\/vulcan-how-razorpay-built-a-foundation-model-for-payment-decisions\/#How_we_measure_it\" >How we measure it<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-16\" href=\"https:\/\/razorpay.com\/blog\/vulcan-how-razorpay-built-a-foundation-model-for-payment-decisions\/#What_the_model_sees_and_what_it_does_not\" >What the model sees, and what it does not<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-17\" href=\"https:\/\/razorpay.com\/blog\/vulcan-how-razorpay-built-a-foundation-model-for-payment-decisions\/#What_reuse_still_has_to_prove\" >What reuse still has to prove<\/a><\/li><\/ul><\/nav><\/div>\n<h2 id=\"s1\"><span class=\"ez-toc-section\" id=\"One_purchase_four_decisions\"><\/span>One purchase, four decisions<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>These decisions belong to the same purchase journey, but none of them can be made well from one payment in isolation. Each becomes reliable only with signals learned across many payments: which methods a customer tends to prefer, how a route has been behaving, how often parcels from a delivery area come back. They also happen at different points and receive useful feedback at different speeds. Routing must finish while the shopper waits. Fraud may take weeks to confirm. For a cash-on-delivery order, the decision is made around checkout, before the payment and delivery outcomes are known.<\/p>\n<p>Because all four problems sit on the same journey, they draw on many of the same underlying signals: how a payment method behaves, how an issuer responds at this hour, what a merchant&#8217;s traffic normally looks like. This is why one deep understanding of payments can serve them all, and it is what Vulcan&#8217;s foundation aims to provide. The nuance sits on top: each decision still needs its own data, its own label and its own way of measuring success, so each gets its own head, a small task-specific layer trained on the shared base.<\/p>\n<h2 id=\"s1b\"><span class=\"ez-toc-section\" id=\"Vulcans_backbone\"><\/span>Vulcan&#8217;s backbone<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p><a href=\"https:\/\/razorpay.com\/blog\/one-foundation-model-built-for-indias-payments-ecosystem\/\" target=\"_blank\" rel=\"noopener noreferrer\">Vulcan&#8217;s public launch<\/a>\u00a0covers routing, fraud detection, cash-on-delivery risk and checkout personalisation. These applications draw on a shared understanding of payments, but they are not four copies of the same model.<\/p>\n<p>In simple terms, a foundation model learns a broad domain before it is adapted to specific tasks. Language models learn patterns in text; Vulcan learns relationships inside structured payment records.<\/p>\n<p>The\u00a0<strong>backbone<\/strong>\u00a0is Vulcan&#8217;s reusable core. It learns common relationships across payment records and turns each payment into a compact numerical summary that task-specific layers can use. Each application still brings its own decision-time inputs, recent context, label, decision layer and way of measuring success. Here, a\u00a0<strong>label<\/strong> is the later-known answer used during training. For example, whether a routed payment succeeded or a parcel was returned.<\/p>\n<figure id=\"attachment_27783\" aria-describedby=\"caption-attachment-27783\" style=\"width: 1724px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-27783 size-full\" src=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.13.07-PM.png\" alt=\"\" width=\"1724\" height=\"556\" srcset=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.13.07-PM.png 1724w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.13.07-PM-300x97.png 300w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.13.07-PM-1024x330.png 1024w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.13.07-PM-768x248.png 768w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.13.07-PM-1536x495.png 1536w\" sizes=\"auto, (max-width: 1724px) 100vw, 1724px\" \/><figcaption id=\"caption-attachment-27783\" class=\"wp-caption-text\">The payment representation is the reusable component. The inputs available at decision time, the label, the head and the release standard remain specific to each application.<\/figcaption><\/figure>\n<\/div>\n<h2 id=\"s1c\"><span class=\"ez-toc-section\" id=\"How_Vulcan_learns_reusable_payment_patterns\"><\/span>How Vulcan learns reusable payment patterns<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The backbone is pretrained across varied payment records spanning payment methods, merchants, issuers, credentials, geography and time. The records are not selected for one downstream outcome such as routing success or fraud. This breadth is what lets the model learn the structure shared by many payment decisions.<\/p>\n<p>A payment record is not a sentence. Its fields do not have a useful left-to-right order, and many fields are absent for a given payment method. Vulcan therefore represents the available fields as a set. Each field carries its identity as well as its value, and a\u00a0<strong>Set Transformer<\/strong>\u00a0learns which fields explain one another.<\/p>\n<p>The self-supervised task is called\u00a0<strong>Masked-Field Prediction (MFP)<\/strong>. During training, some fields are hidden and the model predicts them from the fields that remain. It might see the payment method, amount and time while the issuing bank is hidden. The task is to recover the bank, not to predict fraud or routing success.<\/p>\n<figure id=\"attachment_27784\" aria-describedby=\"caption-attachment-27784\" style=\"width: 1652px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-27784 size-full\" src=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.14.45-PM.png\" alt=\"\" width=\"1652\" height=\"884\" srcset=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.14.45-PM.png 1652w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.14.45-PM-300x161.png 300w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.14.45-PM-1024x548.png 1024w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.14.45-PM-768x411.png 768w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.14.45-PM-1536x822.png 1536w\" sizes=\"auto, (max-width: 1652px) 100vw, 1652px\" \/><figcaption id=\"caption-attachment-27784\" class=\"wp-caption-text\">Vulcan learns from the structure inside the payment record itself. During MFP, outcome and leakage fields are excluded from both the visible inputs and the prediction targets.<\/figcaption><\/figure>\n<\/div>\n<p>The result is a reusable payment representation. A new application can start from that foundation instead of relearning basic payment relationships, while still training and testing the parts that are specific to its decision.<\/p>\n<h2 id=\"s8\"><span class=\"ez-toc-section\" id=\"How_routing_combines_durable_knowledge_with_recent_state\"><\/span>How routing combines durable knowledge with recent state<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Routing needs two kinds of knowledge. The backbone encodes the fields in the current payment and produces a durable payment representation. Separately, a recent-context encoder summarises recent terminal, merchant and gateway activity. Live route-health signals join this second path at decision time.<\/p>\n<p><strong>Fusion<\/strong>\u00a0lets the current payment ask which parts of that recent context matter now. The\u00a0<strong>routing head<\/strong>\u00a0turns the fused context into a score for one eligible candidate. Calibration converts that score into an estimated probability of success. The flow repeats for every eligible candidate, and the routing system orders them by those probabilities.<\/p>\n<figure id=\"attachment_27785\" aria-describedby=\"caption-attachment-27785\" style=\"width: 1624px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-27785 size-full\" src=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.15.36-PM.png\" alt=\"\" width=\"1624\" height=\"796\" srcset=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.15.36-PM.png 1624w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.15.36-PM-300x147.png 300w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.15.36-PM-1024x502.png 1024w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.15.36-PM-768x376.png 768w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.15.36-PM-1536x753.png 1536w\" sizes=\"auto, (max-width: 1624px) 100vw, 1624px\" \/><figcaption id=\"caption-attachment-27785\" class=\"wp-caption-text\">The architecture has two visible paths: durable knowledge from the current payment and fast-moving state from recent network activity and route health. Fusion combines them before the routing head produces a score. Calibration turns that score into an estimated probability of success.<\/figcaption><\/figure>\n<p>With that architecture in mind, the routing problem becomes easier to state: choose well while the shopper waits, using both long-lived payment structure and conditions that may have changed moments ago.<\/p>\n<p><span class=\"hi\">The<\/span> routing problem\u00a0<span class=\"hi\">is then<\/span> easier to\u00a0<span class=\"hi\">state.<\/span>\u00a0<span class=\"hi\">Choose<\/span>\u00a0well while the shopper waits, using both long-lived payment structure and conditions that may have changed moments ago.<\/p>\n<h2 id=\"s2\"><span class=\"ez-toc-section\" id=\"Question_one_which_route_will_succeed\"><\/span>Question one: which route will succeed?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p class=\"q\">Of the paths available to this payment right now, which is most likely to work?<\/p>\n<ul>\n<li><strong>Decision moment<\/strong> &#8211; inside the payment, in milliseconds, while the customer waits<\/li>\n<li><strong>Cost of error<\/strong> &#8211; a customer who wanted to buy is turned away by infrastructure<\/li>\n<li><strong>Core challenge<\/strong> &#8211; there are many possible paths, and their performance can change within minutes<\/li>\n<\/ul>\n<p>When an online payment fails, the shopper waits and then sees an error message saying it did not go through. They had already decided to buy, yet the payment infrastructure turned them away. Some retry; others leave. One failure rarely looks like an incident, but many small failures add up to lost sales. It can also distort checkout analysis: an infrastructure failure may look like shopper abandonment, while a retry prompt that ignores the failed attempt may choose the wrong recovery.<\/p>\n<h3 id=\"s2a\"><span class=\"ez-toc-section\" id=\"What_does_%E2%80%9Cfailure%E2%80%9D_actually_mean\"><\/span>What does &#8220;failure&#8221; actually mean?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>&#8220;The payment failed&#8221; tells us very little. Several different events can produce the same message, and only some of them can improve if we choose another route.<\/p>\n<table dir=\"ltr\" border=\"1\" cellspacing=\"0\" cellpadding=\"0\" data-sheets-root=\"1\" data-sheets-baot=\"1\">\n<colgroup>\n<col width=\"100\" \/>\n<col width=\"100\" \/>\n<col width=\"100\" \/><\/colgroup>\n<tbody>\n<tr>\n<td><strong>What happened<\/strong><\/td>\n<td><strong>Example<\/strong><\/td>\n<td>\n<div>\n<p><strong>Can a different route help?<\/strong><\/p>\n<\/div>\n<\/td>\n<\/tr>\n<tr>\n<td><strong>The route declined<\/strong><\/td>\n<td>The bank refused the payment because of capacity, a risk rule or maintenance.<\/td>\n<td>\n<div>\n<div><strong>Yes<\/strong>. Another path to the same account may work.<\/div>\n<\/div>\n<\/td>\n<\/tr>\n<tr>\n<td><strong>The route timed out<\/strong><\/td>\n<td>No response arrived in time. The payment may even have succeeded without sending a timely confirmation.<\/td>\n<td>\n<div>\n<div><strong>Yes<\/strong>. This is especially costly because the customer waits before seeing the failure.<\/div>\n<\/div>\n<\/td>\n<\/tr>\n<tr>\n<td><strong>It failed late<\/strong><\/td>\n<td>Accepted, then failed at the last step. The customer often believes they have paid.<\/td>\n<td>\n<div>\n<div><strong>Sometimes<\/strong>. Worth predicting because the experience is worst here.<\/div>\n<\/div>\n<\/td>\n<\/tr>\n<tr>\n<td><strong>Customer-side constraint<\/strong><\/td>\n<td>Insufficient balance, wrong PIN, limit exceeded, expired instrument.<\/td>\n<td>\n<div>\n<div><strong>No<\/strong>. Infrastructure routing cannot solve these conditions.<\/div>\n<\/div>\n<\/td>\n<\/tr>\n<tr>\n<td><strong>The customer left<\/strong><\/td>\n<td>The payment app never opened, the request expired or the one-time password was never entered.<\/td>\n<td>\n<div>\n<div><strong>No<\/strong>. This is not an infrastructure failure.<\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<p>&nbsp;<\/p>\n<p>Before Vulcan can score routes, training must separate failures that a route can influence from those it cannot. A wrong PIN or abandoned payment adds noise to the routing signal; declines and timeouts can reveal patterns by route, bank and time of day.<\/p>\n<h3 id=\"s2b\"><span class=\"ez-toc-section\" id=\"What_a_route_actually_is\"><\/span>What a route actually is<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>&#8220;Route&#8221; sounds like one choice. It is not. A payment travels through a specific credential on a specific payment rail. That credential represents one merchant&#8217;s arrangement with one provider. A merchant may have several eligible credentials on the same rail, and two similar credentials can perform differently on the same afternoon.<\/p>\n<p>The shopper chooses the payment method. We choose the path that method takes. The shopper never sees this second decision.<\/p>\n<p>A purchase in India may use the Unified Payments Interface (UPI), a card, netbanking or a wallet. Within each method, the possible paths vary by payment flow, bank, provider, credential and time. A rule that works for one bank at 11 a.m. may be wrong for the same bank at 6 p.m.<\/p>\n<div>\n<figure class=\"fig\">\n<div class=\"analysis-figure\">\n<figure id=\"attachment_27790\" aria-describedby=\"caption-attachment-27790\" style=\"width: 1632px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-27790 size-full\" src=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.22.52-PM.png\" alt=\"\" width=\"1632\" height=\"744\" srcset=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.22.52-PM.png 1632w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.22.52-PM-300x137.png 300w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.22.52-PM-1024x467.png 1024w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.22.52-PM-768x350.png 768w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.22.52-PM-1536x700.png 1536w\" sizes=\"auto, (max-width: 1632px) 100vw, 1632px\" \/><figcaption id=\"caption-attachment-27790\" class=\"wp-caption-text\">The model does not choose a payment method or invent a route. It estimates success for each already-eligible candidate, and the routing system orders the candidates by those estimates. The order shown here is illustrative, not an actual result.<\/figcaption><\/figure>\n<h3 id=\"s2c\"><span class=\"ez-toc-section\" id=\"Why_rules_and_retries_run_out\"><\/span>Why rules and retries run out<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Rules are fast, visible and easy to debug, so they are a sensible starting point. But there are too many combinations of path and condition to describe by hand, and rules grow stale. A rule written for an outage in March may still avoid the route in September, months after it recovered. Because the system no longer tries that route, the better outcome remains unobserved.<\/p>\n<p>Retries help after a failure, but they do not replace a good first choice. The shopper is still waiting, and another route cannot fix an insufficient balance, a wrong PIN or an abandoned payment. Vulcan&#8217;s routing decision has to choose well before a retry is needed.<\/p>\n<figure id=\"attachment_27792\" aria-describedby=\"caption-attachment-27792\" style=\"width: 1724px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-27792 size-full\" src=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.23.49-PM.png\" alt=\"\" width=\"1724\" height=\"332\" srcset=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.23.49-PM.png 1724w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.23.49-PM-300x58.png 300w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.23.49-PM-1024x197.png 1024w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.23.49-PM-768x148.png 768w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.23.49-PM-1536x296.png 1536w\" sizes=\"auto, (max-width: 1724px) 100vw, 1724px\" \/><figcaption id=\"caption-attachment-27792\" class=\"wp-caption-text\">A rule can remain correct in code after it has become wrong in the world.<\/figcaption><\/figure>\n<h2 id=\"s3\"><span class=\"ez-toc-section\" id=\"Question_two_is_this_fraud\"><\/span>Question two: is this fraud?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Is this payment part of a pattern that will turn into a loss?<\/p>\n<ul>\n<li><strong>Decision moment<\/strong> &#8211; at the risk check, before the payment is authorised<\/li>\n<li><strong>Cost of error<\/strong> &#8211; both directions hurt: a loss, or a real customer turned away<\/li>\n<li><strong>Core challenge<\/strong> &#8211; the evidence is spread across merchants who cannot see each other<\/li>\n<\/ul>\n<p>Routing is difficult because paths change quickly. Fraud is difficult because one merchant may see only a small part of an attack. In card testing, attempts can be spread across unrelated merchants so that each business sees only a few ordinary-looking, low-value failures. Across the network, related instruments and tight timing can reveal the pattern.<\/p>\n<p>The confirmed outcome also arrives slowly. Fraud may be confirmed only when a dispute appears weeks later, and some fraud is never reported. We therefore compare detection at the same alert volume: catching more fraud by reviewing more payments is a threshold change, not proof that the model improved.<\/p>\n<figure id=\"attachment_27793\" aria-describedby=\"caption-attachment-27793\" style=\"width: 1644px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-27793 size-full\" src=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.25.08-PM.png\" alt=\"\" width=\"1644\" height=\"568\" srcset=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.25.08-PM.png 1644w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.25.08-PM-300x104.png 300w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.25.08-PM-1024x354.png 1024w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.25.08-PM-768x265.png 768w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.25.08-PM-1536x531.png 1536w\" sizes=\"auto, (max-width: 1644px) 100vw, 1644px\" \/><figcaption id=\"caption-attachment-27793\" class=\"wp-caption-text\">Each merchant sees a few ordinary-looking attempts. The network view supplies the missing unit of analysis: the pattern across merchants, instruments and time.<\/figcaption><\/figure>\n<h2 id=\"s4\"><span class=\"ez-toc-section\" id=\"Question_three_will_this_parcel_come_back\"><\/span>Question three: will this parcel come back?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>If this customer is offered cash on delivery, will the parcel be accepted?<\/p>\n<ul>\n<li><strong>Decision moment<\/strong> &#8211; around checkout or order placement, before the payment or delivery outcome is known<\/li>\n<li><strong>Cost of error<\/strong> &#8211; the merchant pays shipping twice and gets the item back, possibly unsellable<\/li>\n<li><strong>Core challenge<\/strong> &#8211; the available context is limited, and the answer arrives after the delivery attempt<\/li>\n<\/ul>\n<p>Cash on delivery remains important for many Indian shoppers and merchants. But a rejected parcel costs more than a lost sale: the merchant pays for the outward and return journey, ties up working capital and may receive an item that is harder to sell again.<\/p>\n<p>The decision is made around checkout or order placement, when the order, delivery location, cart and available customer context may be known but the payment and delivery outcomes are not. Feedback arrives only after the delivery attempt. A merchant&#8217;s own return history may also be small, so patterns across delivery areas and repeated ordering behaviour become useful.<\/p>\n<p>Checkout asks a different kind of question. The other three are about risk and infrastructure. <span class=\"hi\">This one<\/span>\u00a0is <span class=\"hi\">about<\/span>\u00a0what the shopper is likely to use.<\/p>\n<h2 id=\"s5\"><span class=\"ez-toc-section\" id=\"Question_four_which_method_does_this_shopper_want\"><\/span>Question four: which method does this shopper want?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Magic Checkout, Razorpay&#8217;s checkout, has to order payment choices before the shopper selects one.<\/p>\n<p>Of the payment methods we could show, which will this shopper actually complete with?<\/p>\n<ul>\n<li><strong>Decision moment<\/strong> &#8211; as the checkout page renders<\/li>\n<li><strong>Cost of error<\/strong> &#8211; a shopper hunts for their method, or gives up looking<\/li>\n<li><strong>Core challenge<\/strong> &#8211; the options are nearly identical, and failure is silent<\/li>\n<\/ul>\n<\/div>\n<\/figure>\n<\/div>\n<p>The order matters. A shopper who sees their preferred UPI app near the top can continue immediately; someone who has to search may leave. Unlike routing, the choices can look almost identical. The useful signal comes from the shopper&#8217;s context and earlier behaviour.<\/p>\n<p>Feedback is incomplete. We can see the method a shopper selects, but not the method they wanted and could not find. If the shopper leaves, the data rarely explains whether the ordering caused it.<\/p>\n<p>The four decisions look very different in timing and in feedback.\u00a0<span class=\"hi\">So<\/span> why build one shared model for\u00a0<span class=\"hi\">them,<\/span> instead of\u00a0<span class=\"hi\">carrying on<\/span> with a separate model for\u00a0<span class=\"hi\">each?<\/span><\/p>\n<h2 id=\"s6\"><span class=\"ez-toc-section\" id=\"Why_sharing_matters\"><\/span>Why sharing matters<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Separate models repeat work. Teams prepare similar payment records, define overlapping features and train another base model, while useful learning stays inside the model that discovered it.<\/p>\n<p>Vulcan moves that common learning into the foundation. A new application still needs its own data, label, decision layer and evaluation, but it can start from an existing payment representation instead of rebuilding the base model from the beginning.<\/p>\n<figure id=\"attachment_27795\" aria-describedby=\"caption-attachment-27795\" style=\"width: 1710px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-27795 size-full\" src=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.28.33-PM.png\" alt=\"\" width=\"1710\" height=\"426\" srcset=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.28.33-PM.png 1710w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.28.33-PM-300x75.png 300w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.28.33-PM-1024x255.png 1024w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.28.33-PM-768x191.png 768w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.28.33-PM-1536x383.png 1536w\" sizes=\"auto, (max-width: 1710px) 100vw, 1710px\" \/><figcaption id=\"caption-attachment-27795\" class=\"wp-caption-text\">This is the design goal, not a promise that every new use case is automatic. Reuse must be demonstrated one decision at a time.<\/figcaption><\/figure>\n<h2 id=\"s7\"><span class=\"ez-toc-section\" id=\"What_we_can_see_across_the_network\"><\/span>What we can see across the network<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Several decisions above depend on patterns that one merchant cannot see alone. We can see how the same route, issuer or instrument behaves across many businesses. That network view is one reason a shared payment model is useful.<\/p>\n<p>A bank has a long history of one customer&#8217;s account and can learn deeply about that person. A payments platform sees less of any one person&#8217;s financial life, but it sees payment infrastructure working across many merchants. These are different kinds of information, suited to different questions.<\/p>\n<figure id=\"attachment_27796\" aria-describedby=\"caption-attachment-27796\" style=\"width: 1628px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-27796 size-full\" src=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.29.22-PM.png\" alt=\"\" width=\"1628\" height=\"738\" srcset=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.29.22-PM.png 1628w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.29.22-PM-300x136.png 300w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.29.22-PM-1024x464.png 1024w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.29.22-PM-768x348.png 768w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.29.22-PM-1536x696.png 1536w\" sizes=\"auto, (max-width: 1628px) 100vw, 1628px\" \/><figcaption id=\"caption-attachment-27796\" class=\"wp-caption-text\">Depth helps model a person&#8217;s financial behaviour. Breadth helps model a payment and the infrastructure it must cross. Vulcan is built around the second data shape.<\/figcaption><\/figure>\n<h3 id=\"why-india-s-payment-variety-matters\"><span class=\"ez-toc-section\" id=\"Why_Indias_payment_variety_matters\"><\/span>Why India&#8217;s payment variety matters<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>A purchase in India may use UPI, a card, netbanking or a wallet. Within those methods are many banks, providers and merchant credentials. Their behaviour changes with capacity, maintenance and time of day. This variety makes fixed rules difficult to maintain, but it gives a model useful examples of how payment conditions differ.<\/p>\n<p>The network view is most useful when a simple lookup has little history: a new credential, an instrument seen only once, or a pattern spread across merchants. Vulcan can start from broader payment patterns instead of treating every unfamiliar case as completely new.<\/p>\n<p>The model does not decide what a merchant is allowed to use. Eligibility, merchant configuration and contract rules remain outside the ranking model. Vulcan ranks the choices that are already allowed.<\/p>\n<h2 id=\"s9\"><span class=\"ez-toc-section\" id=\"How_we_measure_it\"><\/span>How we measure it<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>A model number is useful only when the reader knows what it was compared with, which traffic it covered and when that traffic occurred. Without that context, an improvement can be technically correct and still be misleading.<\/p>\n<p>For payment success, the comparison should be the routing logic that would otherwise have handled the same traffic. Absolute success rates move when merchant mix, payment methods or seasonality change, so a before-and-after average is not enough.<\/p>\n<p>Time matters too. A random split lets training and test rows share the same period. We instead train on earlier payments and evaluate on later ones. Results should also be checked by payment flow because a single average can hide one flow improving while another becomes worse.<\/p>\n<p>Ranking and calibration answer different questions. Ranking asks whether the model puts better choices above worse ones. Calibration asks whether a score interpreted as a probability behaves like one. A model can improve the ordering while making its scores less trustworthy, so both need to be checked on later traffic and within the flows that will actually use them.<\/p>\n<p>Routing also has a counterfactual limit: logs reveal what happened on the chosen route, not what would have happened on every route that was available but not selected. Out-of-time tests expose drift, but they do not remove this selection bias. Controlled online evaluation is still needed to measure the causal improvement from changing the routing decision.<\/p>\n<div class=\"evaluation-step\"><strong>1. Train on the past:<\/strong> Learn from payments available before the evaluation window.<\/div>\n<div class=\"evaluation-step\"><strong>2. Test on later traffic:<\/strong> Evaluate on payments from a period the model did not train on.<\/div>\n<div class=\"evaluation-step\"><strong>3. Inspect the slices:<\/strong> Check ranking and calibration by flow; compare fraud at a fixed alert volume.<\/div>\n<div><\/div>\n<div class=\"evaluation-step\">An out-of-time test is closer to deployment than a random split. Segment checks prevent a large flow from hiding damage in a smaller one.<\/div>\n<div><\/div>\n<div class=\"evaluation-step\">The same care is needed when reading the launch figures. For fraud, for example, the 5\u00d7 result was reported without an increase in alerts.<\/div>\n<div>\n<figure class=\"fig\"><figcaption>\n<figure id=\"attachment_27797\" aria-describedby=\"caption-attachment-27797\" style=\"width: 1542px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-27797 size-full\" src=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.31.40-PM.png\" alt=\"\" width=\"1542\" height=\"550\" srcset=\"https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.31.40-PM.png 1542w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.31.40-PM-300x107.png 300w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.31.40-PM-1024x365.png 1024w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.31.40-PM-768x274.png 768w, https:\/\/blog.razorpay.in\/wp-content\/uploads\/2026\/09\/Screenshot-2026-09-10-at-12.31.40-PM-1536x548.png 1536w\" sizes=\"auto, (max-width: 1542px) 100vw, 1542px\" \/><figcaption id=\"caption-attachment-27797\" class=\"wp-caption-text\">This is based on early results, published at launch. They describe different product components and should not be read as four metrics from one experiment. Each was compared against the system it would replace: payment success, by the percentage of transactions that succeeded when routed by Vulcan versus the incumbent routing system; international card fraud and dispute detection, by how many more fraudulent or disputed transactions are caught when using signals from Vulcan, read at the same alert volume; and checkout ordering, by how often a shopper&#8217;s preferred UPI app appeared among the first choices shown.<\/figcaption><\/figure>\n<p><span style=\"font-size: 19px; color: rgba(0, 0, 0, 0.74);\"><span style=\"font-size: 19px; color: rgba(0, 0, 0, 0.74);\">We published these at launch, alongside\u00a0<a href=\"https:\/\/press.aboutamazon.com\/aws-international\/2026\/8\/razorpay-launches-vulcan-indias-first-ai-payments-foundation-model-fueled-by-nvidia-and-aws-re-architecting-payments-for-a-350-bn-e-comm-future-by-2030\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">AWS<\/a>. They were measured on merchants already sending us traffic, so they say nothing about how the model behaves for a merchant with no history, a question we treat separately below.<br \/>\n<\/span><\/span><\/p>\n<h2 id=\"s11\"><span class=\"ez-toc-section\" id=\"What_the_model_sees_and_what_it_does_not\"><\/span>What the model sees, and what it does not<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p id=\"s11\"><span style=\"font-size: 19px; color: rgba(0, 0, 0, 0.74); font-weight: 400;\">Vulcan is trained on transaction records. In the training pipeline described here, listed direct identifiers, including names, email addresses, phone numbers and bank account numbers, are excluded before the training data is written.<\/span><\/p>\n<\/figcaption><\/figure>\n<\/div>\n<figure class=\"fig\">\n<div class=\"metric-grid\">\n<div class=\"metric-card\">\n<p>Some stable categorical references remain because recurring activity can carry useful payment signals. These values are converted to hashed tokens before training, so the model does not receive the original strings. Hashing does not by itself make data anonymous; privacy classification and access controls remain separate responsibilities.<\/p>\n<p>For a pattern such as card testing, recurrence across merchants is the signal. The model can learn that related attempts are appearing across the network without needing a readable card number, email address or shopper name.<\/p>\n<p>Each application also defines a decision-time cut-off. Outcome fields and anything created after that cut-off are excluded from the features used for prediction. Some of those fields may be used later to construct training labels, but the model is not shown information that would have been unavailable when the decision was made. The exact boundary differs for routing, fraud, checkout and delivery risk.<\/p>\n<h2 id=\"s12\"><span class=\"ez-toc-section\" id=\"What_reuse_still_has_to_prove\"><\/span>What reuse still has to prove<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>One foundation does not make the next payment problem free. Every new use case still needs relevant data, a clear label, careful evaluation and a safe serving path. The advantage is that it can begin with a shared payment model instead of rebuilding the base system from nothing.<\/p>\n<p>The real test is whether reuse reduces repeated work and carries useful learning into the next decision without weakening existing applications. The launch results show practical value across routing, fraud, delivery risk and checkout; each application must still establish what it reused and what remained task-specific.<\/p>\n<p>We will judge every use case added to Vulcan the same way. What did it reuse, what still had to be built, and did the result improve the payment decision?<\/p>\n<p class=\"ends\">A companion technical article with AWS will explain how Vulcan is trained and served in more detail. For the public launch story, see\u00a0<a href=\"https:\/\/razorpay.com\/blog\/one-foundation-model-built-for-indias-payments-ecosystem\/\" target=\"_blank\" rel=\"noopener noreferrer\">One Foundation Model, Built for India&#8217;s Payments Ecosystem<\/a>.<\/p>\n<\/div>\n<p><em><strong>About the authors.<\/strong>\u00a0Swaminathan Ravikumar is Head of AI Strategy at Razorpay. He works on where AI can change how payments behave, and which of those problems are worth solving first. Anurag Rastogi is an AI Builder at Razorpay. He designs and trains the Vulcan backbone and its task heads. Ankur Ranjan is a Senior Machine Learning Engineer at Razorpay. He builds and operates the real-time streaming pipelines, feature stores and inference systems behind it.<\/em><\/p>\n<\/div>\n<\/figure>\n","protected":false},"excerpt":{"rendered":"<p>Anyone who has bought something online has been through this journey. To a shopper, a payment is one action: choose a method and click Pay. Behind that action, we have to get many decisions right, from the moment checkout renders to long after the parcel ships. Four of the most consequential: Routing\u00a0is real time: the<\/p>\n","protected":false},"author":165,"featured_media":27798,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[1136],"tags":[],"class_list":{"0":"post-27779","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-ai-payments"},"_links":{"self":[{"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/posts\/27779","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/users\/165"}],"replies":[{"embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/comments?post=27779"}],"version-history":[{"count":31,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/posts\/27779\/revisions"}],"predecessor-version":[{"id":27826,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/posts\/27779\/revisions\/27826"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/media\/27798"}],"wp:attachment":[{"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/media?parent=27779"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/categories?post=27779"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/tags?post=27779"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}