Hacker News Reader

Comment by AaronFriel | Hacker News Reader

Oh wow - gotta wonder how this "arms length transaction" got past any internal auditors or technology officers, or if no one was looking. (Then again, did Citibank have a CTO in the 90s?)

Citibank developing in-house software then selling it to Oracle so that they can charge recurring licensing and support fees for eternity is incredibly short-sighted if you're Citibank or Manna from heaven if you're Oracle.

My guess though is the Citibank executives who signed off on this got promoted up and out of the department that has to budget for these licensing fees and support costs, and on both sides they received tidy bonuses for "increasing revenues".

View on HN

The software fees are likely reduced/free. I've worked at companies that have sold in house software to other companies to make them public. It's usually resulted in lowering in house maintenance costs and the licensing agreements have a sweetheart deal for the original company.

Usually it's a win win, unless you value keeping control (which can be quite valuable)

> Usually it's a win win, unless you value keeping control (which can be quite valuable)

My experience is that it's usually overvalued. An external, focused company will usually do a better job than an internal project. It's emotionally hard to give up control, but successful companies tend to focus on a few things, do them really well (areas of competitive advantage), and outsource everything else.

A best-of-breed external solution almost always beats an in-house solution.

I'd just never do something like this with Oracle. Their business model seems to consist of locking companies in, and then milking them.

> My guess though is the Citibank executives who signed off on this got promoted up and out of the department that has to budget for these licensing fees and support costs, and on both sides they received tidy bonuses for "increasing revenues".

Oracle paid Citibank over US$500 million for this company. There is no way a transaction that big isn't being approved by the CEO and board of directors of both firms. It wouldn't be under the control of the software licensing department. It would be controlled by the business development group in charge of M&As and divestments.

> Citibank developing in-house software then selling it to Oracle so that they can charge recurring licensing and support fees for eternity is incredibly short-sighted if you're Citibank or Manna from heaven if you're Oracle.

I have no internal info on the details of the Citibank-Oracle relationship (my role at Oracle was technical, not the kind of role where I would know that kind of business relationship stuff, and I never worked on the Citibank account either.) But, as @dagmx has already pointed out, I think it is highly likely due to the history of this software that Citibank has some kind of special licensing deal with Oracle which protects them against that sort of thing.

> Oracle paid Citibank over US$500 million for this company.

Maybe they saved the US$500 million they were paid for this software, and they can use it to cover the US$500 million it just cost them.

Even if AaronFriel's assertion is true and they received no special deal, it's a naïve view of corporate governance and SAAS v.s. in-house devleopment to say that (as an example) if their license fee was high enough that they'd start incurring a net loss in 10-15 years that they made the wrong move.

For Citibank that was US$500 million then, which they could either invest directly or return to investors. The opportunity cost of that cash has to be factored in.

It's also an a large ongoing liability to have a sizable in-house development effort when it's not your main business. Departments need to be staffed and run, business plans made etc.

For all of Oracle's flaws they're presumably going to have an incentive to improve the software, and more capital with which to do so from clients other than Citibank. For obvious reasons other banks would be more inclined to buy from Oracle than a direct competitor.

There's also often tax reasons for why it's preferable to buy a service v.s. maintain in-house software, and naïve back of the envelope math usually doesn't account for that.

On the other hand, they also sold one of their core competencies away (managing complex financial transactions) and it just cost them half a billion dollars and who knows how much they've lost since to other errors, let alone lost productivity.

> It's also an a large ongoing liability to have a sizable in-house development effort when it's not your main business. Departments need to be staffed and run, business plans made etc.

This is the same ideology that led to companies outsourcing everything from facility management and cleaning services as the first victims to stuff as critical as IT operations.

Yes, it is a liability and likely also a higher cost (e.g. due to collective wage agreements) to do that stuff yourself. On the other side, you have the large liability of having no direct control over staff and work quality any more - you're entirely at the mercy of your contractors (who are incentivized to find not the best people, but the people willing to be paid the least).

> ...no direct control over...work quality any more...

This is important. Just a few days ago here on HN, there was a good discussion on how deliverables quality on seemingly "mundane" device chargers (in this example, one that was arguably for early Kindles) can vary wildly, while maintaining the same price point, with the sub-standard quality yielding more profits to the seller, and higher-quality units yielding less profits.

This is a impedance mismatch between what the buyer knows and values and what the seller knows and values. With a time slippage between the time the buyer makes a decision and when the buyer's organization figuring out the real ramifications. By the time an organization has outsourced enough to lose competency to not even know the impedance mismatch and time slippage exists or scope it if they're aware of its existence, sometimes they will find might be cheaper to in-source in the first place. My personal rule of thumb going in to evaluate these decisions is if the procedural complexity surrounding such software artifacts rises above a certain level, it is likely better to keep it in-house. Where that level is lays the art of business, it is largely experience-based.

Why would the arms length principle be a concern here? It’s generally only a concern in regards to transfer pricing of transactions between entities that have common ownership/control.

Reply on news.ycombinator.com