> Do we even need monolithic financial entities in this day and age? Most transactions would be better handled by smaller, specialized and modern service companies.
Try dealing with all the special snowflake APIs of twenty or a hundred suppliers of physical goods which are essentially a list of transactions. Then on the other end you mesh with Amex, a merchant gateway for Visa/Mastercard, Paypal, Amazon, etc.
Even "standards" tend to get "adjusted". EDI becomes Vendor X's bastardization of EDI that only resembles EDI at a glance from a non-technical person.
The more "special snowflake" providers you have, the more complex the system becomes and complexity breeds all sorts of inefficiencies. I'd much rather have 50 'monolithic' banks that all abstract things and talk to each other so I only have to deal with "my" bank than 10,000 "financial entities".
> what taxi driver unions are to Uber
I don't want Uber "oh, we'll break regulations and standards because we can get away with it and the contractor is the one that is legally liable" anywhere near any kind of banking system. That attitude would cause all sorts of truly massive problems.
> EDI becomes Vendor X's bastardization of EDI that only resembles EDI at a glance from a non-technical person.
Having spent much of the last decade dealing with systems dealing with EDI in healthcare, I have to say I suspect that largely happens with X-12 EDI standards (at least, the HIPAA mandated ones in healthcare, its possible others are different) because they only resemble suitable technical standards for the intended business domain at a glance from a person unfamiliar with either technology, the business domain, or, ideally, both. (And, on top of that, they are interdependent, each standard is non-free, the standard packaging of all the mandated standards doesn't include the basic standards underlying all of them that they rely on, and even with all the X-12 standards each of them relies on, by reference, dozens of other non-free, third-party standards, for many of which the X-12 standard provides only a postal address for the third-party source.)
Fair enough, but I was mainly using it as an example of a "standard" being not-a-standard-because-too-many-different-implementations and why a monolithic entity would be less prone to this problem.
> Do we even need monolithic financial entities in this day and age? Most transactions would be better handled by smaller, specialized and modern service companies.
Try dealing with all the special snowflake APIs of twenty or a hundred suppliers of physical goods which are essentially a list of transactions. Then on the other end you mesh with Amex, a merchant gateway for Visa/Mastercard, Paypal, Amazon, etc.
Even "standards" tend to get "adjusted". EDI becomes Vendor X's bastardization of EDI that only resembles EDI at a glance from a non-technical person.
The more "special snowflake" providers you have, the more complex the system becomes and complexity breeds all sorts of inefficiencies. I'd much rather have 50 'monolithic' banks that all abstract things and talk to each other so I only have to deal with "my" bank than 10,000 "financial entities".
> what taxi driver unions are to Uber
I don't want Uber "oh, we'll break regulations and standards because we can get away with it and the contractor is the one that is legally liable" anywhere near any kind of banking system. That attitude would cause all sorts of truly massive problems.