Cloud Computing in Finance: Models and Concentration Risk

A component runs in one of three arrangements: on machines the firm operates itself, on capacity it rents and runs its own software on, or inside a service somebody else operates. The three differ in what the firm controls and what it can be told, not in how well the component works. Concentration risk is what is left when several components sit behind one supplier and nobody adds them up.

Nothing about renting capacity changes what a component does. A step that reads a field off a photographed payslip reads the same field whether the machine under it stands in a room the bank pays rent on or in a room the bank has never seen. The arrangement changes three other things: who can make the step stop, who has to be asked before it changes, and how many separate things fail on the same morning. The count of components that fail together is the one no single record answers. Every entry in a firm's own inventory can be true on its own while three of the entries quietly depend on the same supplier. A firm finds that out by asking a supplier a question, not by reading its own file. One bank made exactly that discovery, and the number it found is smaller and more awkward than the word concentration usually suggests.

What are the three arrangements a component can actually run on?

The choice is easiest to see in something physical. A delivery business needs a van. The business can buy a van and keep it in its own yard, so the van is the firm's to service, to repair and to replace, and the van sits idle on the days it is not needed. The business can hire a van by the day, so somebody else buys, services and replaces the van while the firm decides where it goes and what it carries. Or it can hand the parcels to a courier, who supplies the van, the driver and the route, and hands back a delivery confirmation. Three arrangements, one job, and the parcel arrives in all three.

Cloud computing is that same set of three choices about where a piece of software runs, and no more than that. The first arrangement is machines the firm operates itself. The second is rented capacityMachines another firm operates and maintains, on which the buyer installs and runs its own software., where somebody else keeps the machines running and the firm installs and runs its own software on them. The third is a vendor-hosted serviceA finished component the buyer uses and somebody else runs, changes and measures. The buyer sends an input and receives an answer., where the firm sends an input and receives an answer and never touches the software in between. The three differ in exactly one thing: how far down the stack the firm's own control reaches, and every consequence below follows from that single line moving.

What does a Cloud Service Provider supply, and what stays with the firm?

A Cloud Service ProviderThe supplier of rented capacity, or of a finished service running on it. The buyer pays for what it uses rather than buying the machines. is the supplier of the capacity in the second arrangement, or of the finished service in the third. Stripped of the vocabulary, what it sells is the availability of machines the buyer did not have to purchase, plus the promise to keep them running and to replace what fails, plus the ability to supply more of them within the hour. Renting that capacity is a real service and it is worth paying for. The service is also, precisely, all of what a provider sells.

A provider supplies capacity and its upkeep. The accountability for what the firm decided to do with that capacity never leaves the firm. The provider does not decide what a component is used for. The provider does not decide which data may be sent to it. The provider does not hold the name of the person who answers when an applicant complains, it does not write the route back, and it does not stand in front of a supervisor. Every one of those stays exactly where it was before the arrangement existed. At Sumeru Bank Limited, invented, Revathi Balan is the named accountable person for the scoring model whatever machine it runs on, and moving it would have changed nothing about that.

Where do nine real components sit across the three arrangements?

Abstraction is cheap here, so take a real deployment. The intake chain at Sumeru Bank Limited turns a personal loan application started on a handset into a decision, and it holds nine numbered components. In one steady month it took 10,000 applications, carried 8,600 of them to a decision and sent 3,010 of those to a person. The nine components do not all run in the same place, and the split is 6, 2 and 1.

Six of the nine components run on machines the bank operates, two run on rented capacity, and one runs inside a service somebody else operates, and 6 plus 2 plus 1 is 9. The two on rented capacity are component 3, the document classifier, and component 4, the field reading and extraction step. The one inside somebody else's service is component 2, the liveness check on the selfie image. Component 2 is the only one of the nine the bank did not build. Every other component, including the scoring model that determined the outcome of 5,981 of the month's files, runs on the bank's own machines. Read that list once and the chain looks well spread. Hold that thought.

Why did the document work move to rented capacity and the decision work not?

Here is the reason, and it has nothing to do with which components are clever. Four documents arrive on each of the month's 8,600 completed files, making 34,400 document images a month, and the images arrive across 20 working days. If they arrived at the same rate every day, that is 1,720 a day, and a firm sizing machines for 1,720 a day would be right every day of the month. But applications do not spread themselves politely. Applications cluster, and uneven arrivalVolume that lands in lumps rather than at a steady rate, so the busiest day needs far more capacity than the average day. is the single property that makes renting worth paying for.

Renting capacity is worth money exactly where the busiest day sits far above the average day, and it is worth nothing at all where work arrives at a steady rate. The peak day still has to be served, so buying machines means buying the peak and then paying for that peak on every quiet day as well. The arithmetic is plain: if the busiest day is twice the average, half the capacity bought is idle across the month; if it is three times the average, two thirds is idle. Renting instead means paying for the peak on the peak day only. The other side of it is this. The decision work at this bank runs against files as they arrive, in about 4 minutes each, at a rate that barely moves from one day to the next, so there is no peak to avoid buying. Uneven arrival on one side and steady arrival on the other is the whole reason components 3 and 4 moved and component 6 did not.

What is concentration risk, and how does a firm end up with it without deciding to?

Picture a business that ships parcels and has been careful about it. The business deliberately uses three different courier companies, so one of them going down does not stop everything. Then one December it discovers that all three couriers put the overnight load on the same trucking contractor. Nothing any courier said was untrue. Nobody lied. The trucks were one level below where the business was looking, so it diversified couriers and never diversified trucks.

Concentration riskSeveral components depending on one supplier, so that they can fail, change or stop at the same moment for the same reason. is that, in a firm's technology. Concentration is a property of the set rather than of any component, so it appears in no component's own record. A firm sees the concentration only by adding the entries up and asking what sits underneath them. The nine-row table above bears that out. Every row in it is correct. Component 2 really does run inside somebody else's service. Components 3 and 4 really do run on rented capacity. Component 6 really does run on the bank's own machines. There is no error anywhere in that record. No field in it records who is behind the row beside it, so the record still does not show the concentration.

Which question found this bank's own concentration?

The concentration was not found by an audit of the inventory, and it was not found by anybody clever. The finding surfaced at the month 12 validation, when Neelima Rao put question 4 of the bank's own twelve-question supplier assessment to the vendor behind component 2. Question 4 asks what data leaves the buyer, where it lands, and what happens to it there. The agreement behind component 2 had answered 5 of the 12 questions, being 41.7 per cent, and question 4 was one of the five it had answered, in the narrow sense of naming what data leaves. Ask the second half of it out loud and the answer came back: the service runs on the same rented capacity the bank was already using for components 3 and 4.

The concentration lived in a fact the bank's own records had no field for, and one the supplier had never been asked to volunteer. Asking a supplier one ordinary question was the only way to reach it. Sit with that for a moment. There was no concealment. The vendor was not hiding anything, had no reason to, and answered immediately when asked. The information simply sat on the other side of a boundary, and the only instrument that crosses that boundary is a question. A supplier assessment is therefore worth running on every supplier every time rather than only on the ones that feel important: the questions are cheap, and one of them is the only route to something that cannot otherwise be known.

Why did the concentration sit at the front of the chain rather than the middle?

Now the part that turns an interesting fact into a real exposure. Where in a chain the shared supplier sits matters enormously, and at this bank the shared supplier sat in the worst place available. Component 2 is the liveness check. A file that does not clear it never reaches anything else, so every one of the month's 10,000 applications passes through it. Components 3 and 4 handle all 34,400 document images. So the three components that share one supplier stand at the front, in front of everything, and there is nothing to route round them.

Compare that with a shared dependency deeper in. If two components sitting behind the decision engine shared a supplier, the volume exposed would be whatever reaches them. At this bank that is a fraction of the month. The front of a chain is definitionally the part everything passes through, so a shared supplier there exposes the whole volume. The front is also the part a firm is least likely to be looking at when it thinks about where its important components run. People look at the scoring model. The scoring model is the component with a name against it, a validation, a referral band and a monitored output. The scoring model also sits safely on the bank's own machines. The attention and the exposure were in different places.

Does spreading across suppliers make the chain more available or less?

Here the intuition the word concentration produces goes straight into a wall, and it is worth walking into it deliberately. AvailabilityThe share of the time a service is there and answering when something asks it a question. is the share of the time a service answers when asked. Suppose the supplier behind those three components answers 99.9 per cent of the time. All three sit behind that one supplier, so when it is there, all three are there, and when it is not, all three are not. The chain is available 99.9 per cent of the time. Across 10,000 applications a month that is about 10 applications meeting a component that is not answering.

Now do the obvious fix. Move the three onto three different suppliers, each answering 99.9 per cent of the time. The three components sit in seriesArranged so that a file must pass through every step, which means the availabilities multiply rather than adding., meaning a file has to get through all three, so the chain is available only when all three suppliers are. The chain's availability is now 0.999 multiplied by itself three times, being 99.70 per cent, and about 30 applications a month rather than 10. Spreading three components across three independent suppliers roughly triples the interruptions rather than reducing them, and the multiple holds at every level: 100 against 297 at 99.0 per cent, 50 against 149 at 99.5, 10 against 30 at 99.9 and 1 against 3 at 99.99.

How can both halves of the argument be held at once?

So the concentration is bad and spreading is worse. The pair is not a paradox. Two different questions are being answered by two different things, and the only honest position is to say both out loud. One supplier gives better availability and a single point at which everything can be taken away; three suppliers give worse availability and no single point at which anything can. Which matters more depends entirely on which loss the firm fears more, and a firm that states only the half supporting the answer it already prefers has decided the question before asking it.

Spreading buys three things, and availability is not one of them. Spreading buys that the three do not stop at the same moment, so a bad morning takes out one component and not the front of the chain. Spreading buys that no single supplier can force a change on all three at once. The bank's vendor changed component 2 in month 5, and the bank learned of the change in month 6, 15 working days later, from a release note. And spreading buys that no single agreement decides what the bank may test. A term negotiated badly in one contract does not then govern everything the bank runs. All three are real protections, and none of them is an availability number. The bank's own conclusion, at the month 12 validation, was neither option: it left the three where they were and set about writing the route back it did not have.

What has to be true before a component moves to rented capacity at all?

None of the above is an argument against renting capacity. Renting is a good arrangement for work that arrives unevenly, and this bank's document work is exactly that. The question is not whether to move something but whether four things about it can be answered first, and every one of them is about what happens afterwards rather than about how well the component performs today.

The test is four questions, and a no anywhere in the list stops the move. Each no names something that cannot be found out later at any price. Can the firm say exactly what data goes with the component and what happens to it there? Can it say what else of its own already sits behind that same supplier? Can it say what notice arrives before the arrangement changes underneath it? And can it say what it would do in the week the component is not there? The second question is the one this bank could not answer for three years, and it is the cheapest of the four to ask.

What is the route back, and which of the concentrated components had one?

A route backThe written and rehearsed way of continuing the work when a component is not available, including who does it and on what rule. is the written and rehearsed way of getting the work done without a component. Across this bank's nine components, a written route back existed for three, being components 4, 6 and 9, and it had been rehearsed for exactly one, component 6, and only because manual underwriting existed at the bank before the chain did. Against the concentration, the three components sharing one supplier are 2, 3 and 4. The intersection of the two lists is component 4 alone.

Of the three components that would stop together, one had a written route back and none had ever rehearsed one, so the bank's real exposure was two components with no stated way to continue and a third with a document nobody had tested. The month 12 validation produced exactly that finding, and it is why the bank's answer was to write routes back rather than to move anything. A rehearsal is worth being precise about: this bank exercised a written and never rehearsed route once, in month 9, when one channel fell back to manual decisioning for 4 working days at 430 files a day, being 1,720 files, and the desk spent its first morning agreeing what rule to apply. Concentration is a reason to have a route back on every concentrated component, and a route back nobody has run is a document rather than a route.

How does a lender, an analyst or a household actually use this?

Three different people do three different things with the same idea, and it is worth seeing all three because the arithmetic does not change between them. A lender counts. The lender takes its own list of running components, adds a column that no inventory usually carries, being who operates the machine underneath each one, fills that column by asking rather than by reading, and then counts the largest group. The largest group is the exposure, and at this bank it was 3 of 9, being 33.3 per cent, against a bought-or-built reading of the same chain that showed 1 of 9. Across everything the bank ran, 4 of its 14 uses were bought rather than built, being 28.6 per cent. The 28.6 per cent is also not the exposure. A use recorded as built can still hold a bought component inside it. Reading the built-or-bought field is not the same exercise as counting who operates the machines, and at this bank the two readings differed by a factor of three on the same nine components.

An analyst looking in from outside cannot see any of this, and should say so rather than guessing. An analyst can reasonably ask a firm whether it has ever counted, who asked the supplier, and when. A firm that has never asked does not have a low concentration; it has an unknown one, and the two are different things. A household runs the identical exercise without the vocabulary. Everything a person uses in a day may look spread across a dozen services, until the morning the handset is lost and the bank access, the payment method, the ticket, the identity document and the way of contacting anybody about any of it turn out to have been sitting on one object. Nobody decided that. The dependence accumulated, one convenient step at a time, and the only way to find it was to add the list up.

One more thing is easy to miss in a cost discussion, and a lender should notice it. The bank's chain cost Rs 2,40,00,000/- to build once and Rs 65,00,000/- a year to run. Neither figure is split by arrangement anywhere in the bank's record. Rented capacity is the arrangement carrying the concentration, and its cost is not separately visible in the only two numbers anybody quotes about the chain. A firm that manages its arrangements by looking at its cost lines will not see this question at all.