Once the service provider is connected to the Fed (a somewhat complex process), it's normal software development. The client uses either MQI or JMS to send and receive messages; the messages are essentially ISO20022 XML. The development environment could be anything (any OS, any IDE). You interface those messages with your system of accounts. The Fed also provides a simple web UI and a testing network where you can test with other participants and run regression tests.

From a software development perspective, it's really quite normal.

That's really interesting. I worked in PCI (payment cards industry) and we had terminals we could relay the ISO8583 messages through, eventually opting to emulate via software for obvious reasons.

Always so cool to hear about this sort of stuff.

For someone entirely outside of the payments space, what are those obvious reasons please?

generally having to rely on a piece of hardware for high-iteration software development is very unpleasant, so my guess is they chose to abstract what the hardware would do in software for testing/development.

One of the huge pain points I was responsible for was certification of certain payment terminals. Meaning, hardcoded PANs (personal account numbers) written to magnetic stripe cards (or, worse, EMV chips) that have to make physical contact with a reader to transmit data.

Up until a point, we were able to (easily) reproduce these messages via the ISO8583 message format via software. Makes certification much more automation-friendly.

Once we got into hardware encryption/decryption via HSM devices, it wasn't as easily done.

What is normal though? From the perspective of a hardware engineer, from the perspective of a contractor or small company developer, from the perspective of a developer at a medium-sized firm, and from the perspective of an engineer at a FAANG, what is normal is different. Twitter famously doesn't have a dev environment and that's not a bad thing. That's because coordinating umpteen teams to have an actually useful dev-dev and qa-dev env costs more than it's worth, in their eyes. And then, what does normal look like depends on when, too. Local dev envs looked a lot different before Docker came on the scene.

So back to the question, what's the dev env look like? :)

In front of your eyes: TSO-ISPF for everything. IDz for the 5 seconds per month that code is actually written

Test env: Separate permanent envs. From playground where nothing matters, env with some fake data in similar databases and variants of all systems, to mirror of prod with anonymised data, then prod

There are dummy online banking web interfaces

What sets it apart is that the operating system is painful to use and never stops being painful to use. And your employer is paranoid and keeps you in a digital prison for security so very few permissions so there is no creativity or off-road improvisational innovation just assemblyline style development

> And your employer is paranoid and keeps you in a digital prison for security

That, um, sounds reasonable to me in the context of what they're developing.

>> the operating system is painful to use and never stops being painful to use.

But this is regretful, and slows down everything by orders of magnitude. One of the big problems is lack of EFFICIENT documentation/Quick Starts. The guides are labrynthine in layout, looping and colliding spiders' webs of wtfness.

Not really.

Access to production and its data should be highly regulated. Ideally no dev machine has any kind of write access to prod - instead it's commit access to a (non-master) branch which needs multiple approvals to be merged into a release branch.

Access to dev environments and their local code? Who cares, let them explore. As long as all code is reviewed prior to deploying, they could even be developing on a compromised machine and the live system will still be secure.

Practically, if your dev machine was compromised by a targeted attacker, they could create commits using your identity and if they compromised another dev machine could approve those commits using their identity. Then the attack would only be visible in commit logs with low odds of discovery before release to prod.

I'd rather not have "off-road improvisational innovation" with the nation's banking infrastructure, thanks. If that's what you want to do go write another JS framework or static site generator, don't work at a bank.

Your gut reaction is disgust and I don't blame you. You could do without the insults, however. The "nation's banking infrastructure" is outdated and messy. There is no chance in the entire world to upgrade it or clean it up if we the workers are not equipped with the power to do so. A first step could be informational transparency, I would for example really like read access on other systems in the bank and not just my own. Truthfully, separation of duties in this case is more of a controlling function and less of a security function. Of course I care about security, we all do. But let's not stifle the workers that can change the system from within in such low risk work that it's bordering on fear of change. Don't insult me again on something you know nothing about and haven't seen with your own eyes.

It was the royal you, so was not an insult.

I think anything that could be appropriately described as infrastructure could also be described as outdated and messy, so that's not necessarily a reason in and of itself to let people experiment on banking infrastructure. Are software engineers (again, the type who end up working for the federal government and banks and government contractors) any more qualified to experiment on this stuff than people who have working in banking and finance?

Ah okay I get it now. My mistake.

Are they qualified? Sometimes a fresh perspective and courage is what is actually required rather than the home blindness that comes with following the careful bureacratic method for decennia. I would want there to be at least one mechanism in the universe that willpower from the bottom to actually improve the health of the core of these old institutions and companies. There is no mechanism at all currently for the person doing the actual work to take ownership, out of passion or duty, without first climbing the corporate ladder and becoming the grey suit decisionmaker not actually doing the tinkering any more.

I want to be able to own my own risk. If I identify a team need or personal need or business need I want to prototype it autonomously and have the control over my own computer and systems to do so while following all tests and procedures. I can pass it upward for a green light while following all test and development practices. Not only put someone elses decisions into practice while being bottlenecked by guardrails. These old institutions and old companies would pay anything to have something resembling startup agility, but they won't give up any power to self-selected intrapreneurs. I say let me own my own calculated risk . It can even be calculated risk, agreed ahead of time, this happens, that consequence. Off with my head, sure, tell me the cost that comes if I fail with some freedom and if it's losing my job then I'll accept it. If it's paying out of my pocket then I'll accept it. I'm not saying be reckless or not know what sort of risk one is taking. Open the door for calculated personal risk and let me remove the appropriate part of the guardrail. What's the point of being here if I can't use my own life force to change for the better that which crosses my path. Certainly not going to waste time, just fire me or fine me, I agreed to it to do more and better work because I care, hypothetically.

I'll admit the risks that comes with more access, if the risk is uncalculated and can't be owned in scale. Don't take risks, any at all, where the worst outcome is unethical or illegal, for everything that is production and customer data, or where the worst outcome is not even understood or out of scale. So some mindfulness, yes.

If someones personal tool becomes actually useful and the person leaves, then it becomes a weak link in an already unhealthy codebase. Or if they take decisions that don't come from above and somehow have enough access to also leak customer data or cause production issues, then compliance fines could happen. Or getting hacked, or breaking laws with unlicensed software or piracy or anything else, or disrupting other teams, or causing irreversible damage or data loss. Scary, I admit it! I see the paranoia from the top and I empathise!

Let's use bottom-up freedom for replacing the infrastructure with new technology, or lifecycle treatment or archiving, not for entrenching it with new development, or just not knowing what one is doing. But let's not get paralysed with fear. The scale is too heavily tipped in one direction. Shift it in the right direction.