In a way it is isn't though ;-) They are insured against it, they will refund the money back and their risk analysis probably indicates that loosing all that money to fraud is cheaper than waiting and properly deploying and testing the solution.
I imagine just like in the government security world, a lot of bank security is "paper" security (the way I call it). It is a set of formalities, certifications, rubber stamps, audits, other other red tape that in the end all check off and yet the system is still not secure.
They are insured against it, they will refund the money back and their risk analysis probably indicates that loosing all that money to fraud is cheaper than waiting and properly deploying and testing the solution.
This. Some behaviour i encountered by acquiring banks when working on backend software for interfacing with them:
- Authorising a transaction when they failed to contact the issuing bank, because the value of the transaction is lower than a certain threshold.
- Overloading fields in the APACS spec to get around 3D Secure / Verified By Visa, i.e. passing the cardholder straight through the process and then marking it as bypassed (a poorly implemented one factor auth becomes a "eh, this looks ok to me" zero factor auth by the issuing bank).
- Being sat in meetings where the max value of contactless transactions was explicitly stated as being that of a level that any contactless chargebacks were not defended because they're so low.
- Asking me to send PANs in clear text, split over two e-mails (no, i didn't).
Backend backing systems are horrible. Nobody really wants to work on them and they have so much legacy cruft that they're like concrete, so any change takes forever and carries massive amounts of dev/test/risk.
Even the seemingly sensible ones have major WTF's - One of the integrations i did at my previous job was interfacing to Amex's endpoint for online authorisations. HTTPS posts over the web, seems sensible enough right compared to APACS-70 over X.25? No, the ISO-8859-1 POST parameter values needed to be encoded as EBCDIC and then converted to hex (IIRC) before being sent.
Banks playing the chargeback cost balancing game is all well and good for them, but if you're living on the edge and experience fraud then this can lead to all sorts of financial problems.
Having had to re-implement a few legacy systems in newer code for nothing nearly as complex or with as much risk as what you're referring to, I can't imagine any dev not screaming and running for the hills if asked to do this. The chance it will work correctly without bugs early on is close to nil, and the downside for bugs when dealing with financial systems makes the risk analysis being as large as it is, it's pretty clear cut.
I keep telling myself one of these days I'll get to reimplement some system that has good test cases, but I know that will never happen. Any system that is designed well enough to have good tests doesn't really require rewrites in the vast majority of cases.
Comments
In a way it is isn't though ;-) They are insured against it, they will refund the money back and their risk analysis probably indicates that loosing all that money to fraud is cheaper than waiting and properly deploying and testing the solution.
I imagine just like in the government security world, a lot of bank security is "paper" security (the way I call it). It is a set of formalities, certifications, rubber stamps, audits, other other red tape that in the end all check off and yet the system is still not secure.
This. Some behaviour i encountered by acquiring banks when working on backend software for interfacing with them:
- Authorising a transaction when they failed to contact the issuing bank, because the value of the transaction is lower than a certain threshold.
- Overloading fields in the APACS spec to get around 3D Secure / Verified By Visa, i.e. passing the cardholder straight through the process and then marking it as bypassed (a poorly implemented one factor auth becomes a "eh, this looks ok to me" zero factor auth by the issuing bank).
- Being sat in meetings where the max value of contactless transactions was explicitly stated as being that of a level that any contactless chargebacks were not defended because they're so low.
- Asking me to send PANs in clear text, split over two e-mails (no, i didn't).
Backend backing systems are horrible. Nobody really wants to work on them and they have so much legacy cruft that they're like concrete, so any change takes forever and carries massive amounts of dev/test/risk.
Even the seemingly sensible ones have major WTF's - One of the integrations i did at my previous job was interfacing to Amex's endpoint for online authorisations. HTTPS posts over the web, seems sensible enough right compared to APACS-70 over X.25? No, the ISO-8859-1 POST parameter values needed to be encoded as EBCDIC and then converted to hex (IIRC) before being sent.
Banks playing the chargeback cost balancing game is all well and good for them, but if you're living on the edge and experience fraud then this can lead to all sorts of financial problems.
Having had to re-implement a few legacy systems in newer code for nothing nearly as complex or with as much risk as what you're referring to, I can't imagine any dev not screaming and running for the hills if asked to do this. The chance it will work correctly without bugs early on is close to nil, and the downside for bugs when dealing with financial systems makes the risk analysis being as large as it is, it's pretty clear cut.
I keep telling myself one of these days I'll get to reimplement some system that has good test cases, but I know that will never happen. Any system that is designed well enough to have good tests doesn't really require rewrites in the vast majority of cases.
Which EBCDIC CCSID?
At least you knew which encoding to use. For one of our payment integrations we've given up, and just pass it 7-bit ASCII.