Calling all the Visual Basic snitches: Keep quiet about it and so will he...

Regulatory compliance? We've heard of it

Who, Me? If it's Monday, then it must be time for another jaunt to the hallowed confessional of Who, Me? where Register readers confess their, or their co-workers', deepest darkest sins.

Today's story concerns the acquaintance of a reader. Having stuck a hand in The Register's big bag 'o pseudonyms, we shall call the miscreant "Ron".

Ron was gainfully employed performing IT functions for the equities business of an investment bank back in the early noughties. "It was," said our reader, "when Risk was still just a board game."

He worked in a small team of five people, responsible for developing and supporting a business-critical liquidity and capital allocation platform that had to be running whenever trading was occurring.

"Downtime was not an option as their inability to report an accurate position to the regulator meant covering massive (expensive) capital reserves and at worst being told to cease trading."

The poor things.

As a bit of background, the regulatory and compliance environment meant that there had to be a closed period declared around the time of the publication of the annual report. No changes were permitted "lest a fat-fingered or malicious (!) dev cause an outage that tanks the stock."

While this made auditors happy, certain stakeholders in the equities business were less than pleased that their requests for changes could end up stalled during this period. And Ron's team "was 'agile' in that they sat three desks away from the business users and ran features on a whiteboard halfway between themselves and their customers."

So how to keep that pipeline of updates running without any pesky auditors or managers finding out?

"A plan was hatched."

The application concerned was a hulking great Visual Basic client that squatted on a user's local drive. It also connected to an Oracle back-end. When a user fired up the application, it showed a cheery splash screen before allowing a user in.

Ron's team quietly replaced that splash screen with an identical-looking replica which simply queried the Oracle database to see if a new version of the client was available. If there was, it silently slung a .bak on the installed version and pulled down the new code from the build server.

A user might experience a short pause but be blissfully unaware of what had happened as the new client ran up.

Any errors were similarly silently logged, and Ron's team notified. Also, Ron "had automated an email address that would respond to a specific message body syntax, decrement the version and a timed checker on the client would notify any logged-on users that an issue had occurred and they needed to restart. The splash screen / backup & revert would happen again and the customer would log back in, none the wiser."

We put this scenario to some anonymous fellows in the financial industry, and all were a tad alarmed. While the odd patch is part and parcel of life, a wholesale update that could alter data in the closed period is a no-no.

And, of course, the process continued through Witchings (the last hour of stock trading) and mergers, with bosses unaware of the wheeze concocted by the development team to keep the users happy.

It took three years before Ron made his confession, lubricated by guilt and the odd beverage or two. Of course, he had long since moved on to another bank.

"Not a single problem ever occurred, and the business and IT never twigged."

Of course, there was that whole financial crisis in the last decade, but we're sure Ron's antics were entirely unconnected.

Ever bent some rules beyond breaking point and skipped lightly away from the clutches of the auditors in order to make life a little less hellish for users? You have? Send us an Who, Me? and tell us all about it. ®

Sponsored: How to Process, Wrangle, Analyze and Visualize your Data with Three Complementary Tools

SUBSCRIBE TO OUR WEEKLY TECH NEWSLETTER




Biting the hand that feeds IT © 1998–2019