Razorpay's Vulcan makes the prediction target the architecture question

Razorpay introduced Vulcan on August 18 as a transformer-based foundation model for payments, explicitly distinguishing it from a language model. The company's announcement carried by AWS describes shared learning across payment routing, fraud and risk decisions.

That distinction is more useful to an architecture review than another contest over whose launch contains the largest training-data number.

I would start with the prediction target. If the system must decide how to route a payment, the design should explain the evidence available at that moment and the outcome it is trying to improve. A conversational interface is a separate choice.

A decision does not have to become a paragraph

An LLM can be useful around a payment workflow: explaining a process, helping an operator investigate or translating a request into an authorised action. Those uses do not establish that every underlying decision should be made by serialising transaction data into text and asking for an answer.

The choice depends on the task, data, latency and evaluation requirements. Vulcan supplies a concrete example of a vendor choosing a domain model for several related decisions. Its launch does not prove that the same choice is appropriate for every organisation.

As an illustration, imagine I am reviewing a hypothetical transaction-routing service. Before comparing models, I would write down the available inputs, the permitted outputs and when the decision must arrive. I would also identify which information becomes available only after the transaction has completed.

That last distinction matters. A training dataset can contain fields that make an outcome easy to predict after the event but cannot be used at decision time. A promising offline result must survive a test using only the evidence the live service will actually have.

I would compare candidate approaches against the same operational baseline and acceptance criteria. A more elaborate model needs to justify its integration and serving burden through results on the intended task. The foundation-model label cannot do that work for it.

Shared learning still needs separate outcome checks

Routing and fraud decisions can draw on overlapping data while producing different kinds of mistakes. A system that improves one outcome could still make another worse. I would keep the acceptance tests separate even where the model representation is shared.

For the hypothetical service, that means tracking successful transactions alongside relevant risk outcomes and the time taken to decide. A single blended score can hide a tradeoff the business would not willingly accept. The owner of each decision needs to see its own result.

Razorpay publishes performance improvements for Vulcan on its product page. They are vendor-reported outcomes. Without the full comparison design and an independent evaluation, I would use them to formulate questions for a pilot, not as savings or performance promises for another business.

The useful architectural lesson survives that limitation. Begin with the event and the decision, choose an appropriate representation, and test against the consequences that matter. Add language generation where language helps a person or system perform a defined job.

For the next “add AI” request, ask the team to state the prediction target in one sentence before naming the model. That sentence is often the most valuable part of the design review.

Choose the model around the decision you need to make, not around the assumption that every AI input should become text.