Traditional Challenges with LARGE Vendors
"LARGE vendors wouldn't cut corners, would they?"
When Basel II was first announced, every company working within even an extrapolated proximity to the Basel space rushed headlong towards El Dorado. To have created such a solution from scratch would have meant taking a product to market second or third and missing out on some very easy, premature sales. For that reason, you will sadly find only one product in the market place which was not ‘bolted-onto’ an existing application and has no reliance on large, third party, proprietary tools. These measures will always greatly assist in getting a product to market in a rush, but exhibit large, and not unexpected, ‘cracks’ when the patina has worn away. Since the focus for most software houses was ‘speed to market’, rather than a design which would stand the test of time, what remains are difficult, if not impossible footprints to maintain.
In one such case, one of the largest software vendors in the world took an entire month just to specify training courses for its Basel solution because it could not safely determine which modules of its pre-existing spaghetti it had used .
In another instance, a large vendor built its multi-million dollar Basel solution out of aging, 30 year old proprietary components with not surprising results. After struggling for 2 whole months with a Severity 1 defect, (that is ‘a total outage to the system’), it was forced to add a band-aid to its software which multiplied an interim value by 1,000,000 and later divided the same number by 1,000,000 before creating an RWA. Without this ‘fudge’, every exposure would crash the system. Several months later, while testing against a different regulator for the same bank, it was sadly discovered that exposures within this new jurisdiction were required to be multiplied and later divided by 10,000, instead of 1,000,000. Currently, both of these band-aids must exist or the solution will crash on every exposure. The root cause has never been determined.
In another case, the largest financial software house in the world had sold a solution which relied on a large, third party, proprietary tool. The manufacturer of the tool dropped support of its product for the bank’s strategic platform. The bank, too afraid of upsetting its relationship with vendor, allowed itself to be forced off its strategic Unix platform in deference to Windows in order to suit the vendor’s needs.
In yet another instance, one of the largest financial software houses in the world attempted to get a Basel solution to market quickly by attaching some Visual Basic code to a very old, very proprietary rules based engine. (first commissioned in 1984) After making a sale to one of the largest banks in the world, the bank worked around the clock for 6 weeks to attempt to process a single exposure. When not even this could be achieved, the solution was thrown out and a replacement sought. As the deal was on the verge of collapse the Managing Director of the software house was quoted as saying, “What do you expect? It only cost $2 million.” But…there may just be a solution on the horizon which enjoys the benefits of 4 years of design & creation, which was less concerned about the ‘quick-buck’, and more concerned with being the ‘ultimate-solution’. Its fully scalable design is based on only 100% state of the art Open Source paradigms; no linkages to old components, and no proprietary tools. This design allows your bank to create as many environments as you like, quickly and safely, from a stand-alone laptop for an Executive demonstration to a massive production instance, any hardware, any operating system, any database. We can have you calculating exposures within an hour… Why not talk to us at RegCap?
|