6 ms·

OpenTransact a tiny payment standard

22 points by pelle 17y ago

xal 17y ago
Very clever. I hope this works out.
sern 17y ago
Too simple. The banks will never adopt it.
- pelle 17y ago
  Innovators dilemma. If the banks want to adopt it then cool, if not more opportunities for innovators. The regulators though are the real issue, but we have some ideas for dealing with them as well.
  - freetard 17y ago
    This is awesome work, congrats. Have you been in contact with some banks about it already?
    - pelle 17y ago
      Thanks. I am probably not going to talk directly with banks, but I know there are people from the traditional banking and payment card world on the Agile Banking list and I'm hoping one or two smart banks might use the economy as an excuse to innovate.
kiwidrew 17y ago
Unfortunately, there's a reason why banks and other financial institutions tend to batch transactions together and settle them overnight: liquidity requirements. Basically, the shorter the settlement period, the more cash the banks need to keep immediately accessible. The increased liquidity requirement carries with it the opportunity cost of keeping that cash available at-hand instead of in more productive investments. With end-of-day settlement, each bank only needs to transfer the _net_ amount (outgoing transfers minus incoming transfers), which is -- barring a really nasty run on one of the banks -- an order of magnitude smaller. So there's a tradeoff between settlement speed and transaction cost. But this doesn't prevent the bank from immediately notifying the recipient of the funds that a transfer has been made. It's just that the funds aren't available for use until after settlement. For some interesting details about the tradeoff between settlement delay and transaction costs, I found http://ideas.repec.org/p/bca/bocawp/06-20.html http://ideas.repec.org/p/bca/bocawp/06-20.html to be an interesting read.
- pelle 17y ago
  You are absolutely right about that. Which is another reason why traditional banks are a not likely to jump on this straight away. Liquidity is not an issue for most of the applications I hear planed using OpenTransact as they typically operate with 100% reserves. I am very particular personally to the Narrow Banking http://en.wikipedia.org/wiki/Narrow_banking http://en.wikipedia.org/wiki/Narrow_banking ideas as a replacement for the traditional monolithic multipurpose banks, where again this would not be an issue. Taking a hypothetical narrow banking world to it's extreme using OpenTransact a typical everyday bank consumer needs could be split by functionality into 5 different narrow companies with each their function: * A financial supermarket end that only resells financial services to replace the traditional bank branch * A narrow banking cash account structured as a cash mutual fund. 0% interest, 100% reserve. * A money market mutual fund for savings * A card issuer linked to your cash account offering a visa debit card service * One or more exchanges for transferring funds between banks instead of ACH I am not even mentioning credit here, but credit and insurance can all be offered by different institutions like http://prosper.com http://prosper.com again using the Narrow banking model. Obviously the above example assumes that our financial needs are all going to be the same as today. More than likely we will see financial products that are completely different than what we see today. In particular because the existing banks are not likely going to give up their existing revenue sources.
freetard 17y ago
Some nice demos of how it works: http://www.opentransact.org/usecases.html#simple http://www.opentransact.org/usecases.html#simple
deleted 17y ago
[deleted]
joshu 17y ago
I'm not sure what problem this solves. Go look at the spec for FIX. This is what's necessary to specify modern financial transactions. I'm not sure that naming endpoints is really that helpful to any particular problem. You've replaced a CUSIP with a URL, I guess.

22 points by pelle 17y ago

xal 17y ago

Very clever. I hope this works out.

sern 17y ago

Too simple. The banks will never adopt it.

pelle 17y ago
Innovators dilemma. If the banks want to adopt it then cool, if not more opportunities for innovators. The regulators though are the real issue, but we have some ideas for dealing with them as well.
- freetard 17y ago
  This is awesome work, congrats. Have you been in contact with some banks about it already?
  - pelle 17y ago
    Thanks. I am probably not going to talk directly with banks, but I know there are people from the traditional banking and payment card world on the Agile Banking list and I'm hoping one or two smart banks might use the economy as an excuse to innovate.

kiwidrew 17y ago

Unfortunately, there's a reason why banks and other financial institutions tend to batch transactions together and settle them overnight: liquidity requirements. Basically, the shorter the settlement period, the more cash the banks need to keep immediately accessible. The increased liquidity requirement carries with it the opportunity cost of keeping that cash available at-hand instead of in more productive investments. With end-of-day settlement, each bank only needs to transfer the _net_ amount (outgoing transfers minus incoming transfers), which is -- barring a really nasty run on one of the banks -- an order of magnitude smaller. So there's a tradeoff between settlement speed and transaction cost. But this doesn't prevent the bank from immediately notifying the recipient of the funds that a transfer has been made. It's just that the funds aren't available for use until after settlement. For some interesting details about the tradeoff between settlement delay and transaction costs, I found http://ideas.repec.org/p/bca/bocawp/06-20.html http://ideas.repec.org/p/bca/bocawp/06-20.html to be an interesting read.

pelle 17y ago
You are absolutely right about that. Which is another reason why traditional banks are a not likely to jump on this straight away. Liquidity is not an issue for most of the applications I hear planed using OpenTransact as they typically operate with 100% reserves. I am very particular personally to the Narrow Banking http://en.wikipedia.org/wiki/Narrow_banking http://en.wikipedia.org/wiki/Narrow_banking ideas as a replacement for the traditional monolithic multipurpose banks, where again this would not be an issue. Taking a hypothetical narrow banking world to it's extreme using OpenTransact a typical everyday bank consumer needs could be split by functionality into 5 different narrow companies with each their function: * A financial supermarket end that only resells financial services to replace the traditional bank branch * A narrow banking cash account structured as a cash mutual fund. 0% interest, 100% reserve. * A money market mutual fund for savings * A card issuer linked to your cash account offering a visa debit card service * One or more exchanges for transferring funds between banks instead of ACH I am not even mentioning credit here, but credit and insurance can all be offered by different institutions like http://prosper.com http://prosper.com again using the Narrow banking model. Obviously the above example assumes that our financial needs are all going to be the same as today. More than likely we will see financial products that are completely different than what we see today. In particular because the existing banks are not likely going to give up their existing revenue sources.

freetard 17y ago

Some nice demos of how it works: http://www.opentransact.org/usecases.html#simple http://www.opentransact.org/usecases.html#simple

deleted 17y ago

[deleted]

joshu 17y ago

I'm not sure what problem this solves. Go look at the spec for FIX. This is what's necessary to specify modern financial transactions. I'm not sure that naming endpoints is really that helpful to any particular problem. You've replaced a CUSIP with a URL, I guess.