I have worked on highly regulated areas in finance (risk). Compliance is a highly creative art, often requiring lots of out-of-the-box thinking and non-obvious solutions. The people I found worst at this were IT. They tend to over-interpret regulation, and super-restrict beyond what is needed for actual de-facto compliance.

My guess is the model makes the same mistakes as the programmers: taking 'rules' literally, unaware of sectoral joint understanding, validated interpretations and habits. (btw. this is often on the non-tech side also a difference between regulatory and legal. The former are much more result oriented while the latter are primarily risk averse.

▲

davedx 8 minutes ago | parent | next [-]

Ha. I've worked in a fairly strongly regulated sector (energy, in the Netherlands), where I collaborated closely with our head of compliance, and she heavily over-interpreted the regulations while I often tried to find more pragmatic solutions.

I think adherence to regulation and compliance is nothing to do with whether you're a SWE, a risk officer, or C-level, and everything to do with your own principles, ethics, professional attitude, and pragmatism.

▲

thewebguyd 2 hours ago | parent | prev | next [-]

> IT. They tend to over-interpret regulation, and super-restrict beyond what is needed for actual de-facto compliance.

IME this is less the fault of IT and more so bad auditors that won't consider, or just don't understand, what compensating controls are. If it doesn't meet their little checklist exactly, they fail the audit.

▲

antonvs 19 minutes ago | parent | next [-]

> IT. They tend to over-interpret regulation, and super-restrict beyond what is needed for actual de-facto compliance.

This is such a nonsensical claim. If a company is asking someone from IT to read the regulations and implement them, then obviously you’re going to get something that conforms to the written specification they were provided.

But a company that does that is basically delegating both compliance and legal functions to IT. No sane company does that.

▲

hparadiz 2 hours ago | parent | prev [-]

It's cause IT never has to live with the consequences of their decisions. Who cares if the other department keeps bleeding talent because you twisted the knobs so hard no one wants to work in your system?

▲

JimBlackwood an hour ago | parent [-]

Sounds like communication between departments sucks. If IT develops for them, you’d expect there to be a feedback loop?

	▲	hparadiz an hour ago \| parent [-]
		Yes. Exactly. This is not a reflection of where I am now in any way shape or form. Just my observation of previous places I've worked.

▲

jayd16 2 hours ago | parent | prev [-]

Who gets in trouble if it turns out you are actually held to the literal rule?

▲

PeterStuer 2 hours ago | parent | next [-]

Contrary to what you indicate rules are not declared in a vacuum, for people to read and then algorithmically 'implement'. There are many ways to interpret regulation, and there will be both accompanying clarifications, as well as compliance departments negotiating with regulators on what is an acceptable and sufficient compliance action. Then there furthermore is a risk that will be calculated vs the cost and opportunity costs etc.

As an enterprise architect, these are all part of the meetings you have with compliance when you are working on major projects. I have had the privilege of working with some excellent compliance officers, and they are the opposite of the nay-saying caricature that is often painted of them. I found these people to be extremely creative and helpful, working together towards solutions rather than stalling or nixing viable progress.

▲

logicalmind an hour ago | parent | next [-]

I also work in finance and my recent experience with regulators is really discouraging. DOGE wiped out a large amount of the regulators in government. It seems like most of the regulators remaining are the inexperienced and low tenure. Within the past few months we've attempted to roll out new financial products. When we attempt to send our proposal to them, they can't even tell us who we're supposed to send it to.

It doesn't feel like we're living in the same world of regulation that existed prior to DOGE.

▲

jayd16 2 hours ago | parent | prev | next [-]

The point was about who is on the hook and why they might be less permissive.

I'm not implying anything else. I used your own "literal" wording to refer to the "more strict than yours" interpretation.

I suppose I should have used scare quotes around "literal".

▲

PeterStuer 2 hours ago | parent [-]

'The company' would be on the hook. Inside, it might be the compliance team that signed off on the solution, but it usually is not the sort of blame game at that point. I'm not saying these scapegoat trails do not exist, but they are far less common than you would imagine if you only read about them in the press.

Company politics, feudal wars, fiefdom protections, backstabbing and outright sabotaging, now there's a daily occurrence and many minions are cannon fodder in those skirmishes, but they usually stay clear of regulatory issues minefields.

▲

rectang 2 hours ago | parent [-]

I am skeptical that developers who implement a non-compliant solution that gets a company in trouble get off scot-free.

If the company you work for actually had such a no-fault culture, I doubt you'd be criticizing programmers so aggressively for being sticklers, but would instead be trying to understand and account for the systemic factors (including human factors) behind their behavior.

	▲	fauigerzigerk 30 minutes ago \| parent [-]
		>I am skeptical that developers who implement a non-compliant solution that gets a company in trouble get off scot-free. I don't see why developers should be in trouble. Developers don't make unilateral decisions on non-trivial compliance matters. A finding of non-compliance at a financial institution would typically be the result of an investigation, a disagreement with the regulator or a court ruling. It would come years after the organisation as a whole decided to adopt the interpretation in question.

▲

kanbankaren an hour ago | parent | prev [-]

> There are many ways to interpret regulation,

Then the rules should enumerate all the ways. From your posts, you come across as if programmers don't know what they are doing which is insulting to those who work in mission critical industries like aviation where a programmer could be criminally charged if he/she didn't implement the specs STRICTLY.

	▲	PeterStuer an hour ago \| parent [-]
		"you come across as if programmers don't know what they are doing" Is neither what I said nor believe.

▲

scott_w 2 hours ago | parent | prev | next [-]

That's why you work with your Legal/Compliance Team to make sure you stay in line. They can explain when a rule applies and when it doesn't. This needs the engineering side to be able to explain what's happening, and translate it into the business process as closely as possible, and the legal side to be able to apply the law to the case.

▲

tsunamifury 2 hours ago | parent | prev [-]

If you think rules are literal than you aren’t aware how the world works.

There’s a reason it’s called “judgement”

▲

rectang 2 hours ago | parent | next [-]

In your world, do subordinates ever get scapegoated for bending the rules at a boss's behest?

▲

2 hours ago | parent | prev | next [-]

[deleted]

▲

jayd16 2 hours ago | parent | prev [-]

...And that judgement could take them literally. So what is your point?

My point was simply that it's easy to scoff at someone else being careful if it's their neck and not yours.

	▲	parineum 2 hours ago \| parent [-]
		They could but they don't. That's pretty much the whole job. You can also appeal decisions to a more reasonable party if you draw RobotJudge3000 for your trial