Standardization of asset class identifiers

[Andreas Pizsa]

During my work on OpenToken, I came across the problem of uniquely
identifying asset classes, and I would like to propose the
standardization of asset class identifiers also in the context of the
OWP standard.

*** Why asset class identifiers?
There are several existing standards in the financial community as to
how to specify an asset class, where "asset class" is any kind of
security, including currencies.

ISO 4217 - Currency Codes
NASDAQ Ticker Symbols (AAPL, C, HPQ, etc)
ISIN / ISO 6166 (http://en.wikipedia.org/wiki/
International_Securities_Identifying_Number)
etc etc.

Beyond just plain naming issues, there are some other not-so-obvious
benefits to using asset identifiers, especially when it comes
identifying the issuer of an asset class; e.g. it would be interesting
to see what kind of asset class a fractional reserve bank would use
when they issue an essentially unbacked loan; it couldn't be
"org.federalreserve.usd", because they wouldn't be legally authorized
to issue FED notes, would they, so that would essentially be an act of
fraud...

*** Requirements for a standardized Asset Class Identifier

• uniquely identify an asset class globally
• avoid namespace conflicts
• identify the issuer of the asset class
• decentralized allocation of identifiers

Standardizing the asset class identifier amongst different systems
would make interopability between them easier.

*** Proposal

My simple proposal is to use the Domain Name System in reverse dotted
notation (inspired by the Java convention for fully qualified class
names)
e.g.

org.nasdaq.aapl
org.iso.6166.us0378331005
org.iso.4217.usd

So, to steal form Wikipedia

Parts of an Asset Class Identifier
• A domain name consists of one or more parts, technically called
labels, that are conventionally concatenated, and delimited by dots,
such as org.nasdaq.
• The LEFT-most label conveys the top-level domain; for example, the
domain name org.nasdaq belongs to the top-level domain org.
• The hierarchy of domains descends from the LEFT to the RIGHT label
in the name; each label to the left specifies a subdivision, or
subdomain of the domain to the right. For example: the label nasdaq
specifies a subdomain of the org domain, and aapl is a subdomain of
org.nasdaq. This tree of labels may consist of 127 levels. Each label
may contain up to 63 ASCII characters. The full domain name may not
exceed a total length of 253 characters.

I appreciate any comments and further suggestions!

Best,
A.

[Joshua Reich]

This is a hard problem to solve (http://blog.i2pi.com/?p=126). Bloomberg made some waves recently by opening up their symbology: http://bsym.bloomberg.com/sym/

--
Joshua Reich, CEO Simple Finance Technology
http://banksimple.net/about
18 Bridge St, #4F Brooklyn, NY, 11201
(c) 646 256 4763 (o) 718 855 8231

--
You received this message because you are subscribed to the Google Groups "agile-banking" group.
To post to this group, send email to agile-...@googlegroups.com.
To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.

[Pelle Braendgaard]

I kind of like this proposal as the reverse domain name method allows a certain amount of flexibility. We can decide on some hard asset types such as currency iso codes but at the same time allow flexibilty to support new and proprietary schemes.

Joshua, good point about the complexity. It is always a problem when you try to create a system to handle every kind of case. Which is why I'm so passionate about OpenTransact delegating things like asset classes to URIs. The white paper from bloomberg has plenty of examples of why this is important. http://bsym.bloomberg.com/sym/pages/bsym-whitepaper.pdf

Using Andreas approach together with BSYM you could get:

com.bloomberg.bsym.EO1016052010040181900001 to signify April 10 Calls on VOD US (US Composite)

I'm not sure about this yet. Might it be better to use an actual URI where you could go and get metadata about it?

P

--
http://agree2.com - Reach Agreement!
http://stakeventures.com - My blog about startups and agile banking

[Andreas Pizsa]

> I'm not sure about this yet. Might it be better to use an actual URI where
> you could go and get metadata about it?

Absolutely. Aren't naming and meta data location are two different
concepts? Naming would be a URN, while the whole Metadata Discovery
and Location stuff is XRI, as far as I understand it.

What I dislike about the URL solution is that it requires that the
location actually contains information about the asset class, which in
the cases of

http://bloomberg.com/bsym/EO1016052010040181900001
http://bsym.bloomberg.com/EO1016052010040181900001
http://nasdaq.com/AAPL
http://federalreserve.gov/USD

is probably not going to happen anytime soon. I also think that an
open standard shouldn't dictate a certain URL path structure - that's
really an issue of Discovery.

If we need URIs, how about using the URN schema?

urn:x-asset:com.bloomberg.bsym.EO1016052010040181900001
urn:x-asset:gov.federalreserve.usd
urn:x-asset:com.goldmoney.aug
urn:x-asset:usd
urn:x-asset:eur

;)

A.

On 22 Jul., 17:50, Pelle Braendgaard <pe...@stakeventures.com> wrote:
> I kind of like this proposal as the reverse domain name method allows a
> certain amount of flexibility. We can decide on some hard asset types such
> as currency iso codes but at the same time allow flexibilty to support new
> and proprietary schemes.
>
> Joshua, good point about the complexity. It is always a problem when you try
> to create a system to handle every kind of case. Which is why I'm so
> passionate about OpenTransact delegating things like asset classes to URIs.
> The white paper from bloomberg has plenty of examples of why this is

> important.http://bsym.bloomberg.com/sym/pages/bsym-whitepaper.pdf

>
> Using Andreas approach together with BSYM you could get:
>

> com.bloomberg.bsym.EO1016052010040181900001 to signify* April 10 Calls on
> VOD US (US Composite)*

>
> I'm not sure about this yet. Might it be better to use an actual URI where
> you could go and get metadata about it?
>
> P
>
>
>
>
>
> On Thu, Jul 22, 2010 at 11:22 AM, Joshua Reich <j...@i2pi.com> wrote:
>
> > This is a hard problem to solve (http://blog.i2pi.com/?p=126). Bloomberg
> > made some waves recently by opening up their symbology:
> >http://bsym.bloomberg.com/sym/
>
> > --
> > Joshua Reich, CEO Simple Finance Technology
> >http://banksimple.net/about
> > 18 Bridge St, #4F Brooklyn, NY, 11201
> > (c) 646 256 4763 (o) 718 855 8231
>

> >> agile-bankin...@googlegroups.com<agile-banking%2Bunsubscribe@goog legroups.com>
> >> .

> >> For more options, visit this group at
> >>http://groups.google.com/group/agile-banking?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "agile-banking" group.
> > To post to this group, send email to agile-...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > agile-bankin...@googlegroups.com<agile-banking%2Bunsubscribe@goog legroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/agile-banking?hl=en.
>

> --http://agree2.com- Reach Agreement!http://stakeventures.com- My blog about startups and agile banking

[Guillaume Lebleu]

Several small thoughts.

On assets vs units of value: I think we ought to distinguish units of
account from assets. Checking money at a bank is an asset measured in
units of USD, but it's not USD, just checking money issued by the bank
convertible on demand in USD (Fed notes or Fed reserves on a Fed
account), so the asset is bank.com/checking or com.bank.checking and
the unit is USD. I don't recommend placing the unit in the URL (ex.
http://bank.com/checking/USD). To go back to OpenTransact and banking/
payment APIs in general, to me the URL points to the asset, but the
response ought to provide the value and the unit, possibly multiple
values in multiple units of value.

On transactions: transfers within an asset should be very simple: ex.
transfer from my checking to my savings or to my checking at bank.com/
checking to my child's checking at bank.com. Payments on the other
hand are much more complicated b/c they are typically meta-
transactions, a series of balancing transactions each within a given
asset, with one of them typically being two accounts at the Fed
reserve.

I think values/amounts should be forced to (big) integers in APIs. The
cent is actually the official unit of the USD.

Guillaume

On Jul 22, 12:43 pm, Andreas Pizsa <hops...@gmail.com> wrote:
> > I'm not sure about this yet. Might it be better to use an actual URI where
> > you could go and get metadata about it?
>
> Absolutely. Aren't naming and meta data location are two different
> concepts? Naming would be a URN, while the whole Metadata Discovery
> and Location stuff is XRI, as far as I understand it.
>
> What I dislike about the URL solution is that it requires that the
> location actually contains information about the asset class, which in
> the cases of
>

> http://bloomberg.com/bsym/EO1016052010040181900001http://bsym.bloomberg.com/EO1016052010040181900001http://nasdaq.com/AAPLhttp://federalreserve.gov/USD

> > --http://agree2.com-Reach Agreement!http://stakeventures.com-My blog about startups and agile banking

[Pelle Braendgaard]

I agree on separating units from assets. I think it's a good insight to do so. 

I think it would be absolutely fine though to include a currency unit in the url as long as we just understand it is a opaque object with respect to OpenTransact.

Also good insight in the difference between a transfer and a payment. However for OpenTransact it is simply an implementation issue. Whether it is a single or a series of book entry transactions is really an implementation interface.

You could imagine a bank offering an OpenTransact system for doing swift like transfers accepting an IBAN in the "to" field:

http://en.wikipedia.org/wiki/International_Bank_Account_Number

I am trying to come up with a suggestion for a full stack using OpenTransact. Having a unit field would be useful. 

P

To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.

--

http://agree2.com - Reach Agreement!

http://stakeventures.com - My blog about startups and agile banking

[Andreas Pizsa]

> On assets vs units of value: I think we ought to distinguish units of
> account from assets. Checking money at a bank is an asset measured in
> units of USD, but it's not USD, just checking money issued by the bank
> convertible on demand in USD

Agree, and I think that's the best reason why standardized asset class
identifiers are beneficial.

Technically, what's happening here is that the bank actually issues a
new security - a new asset class. A com.bankofamerica.usd is something
entirely different than a gov.fed.usd and there should be mechanism on
the design level that makes such things transparent. Trustworthy
issuers will gladly publish the quantity of their assets in
circulation; doing so for com.bankofamerica.usd / gov.fed.usd and
other assets will definitely paint a different picture than thinking
that these are 1:1 relationships, as banks would want you to believe.

Fellow Traveller suggests that the asset class identifier should be
the hash of the actual securities contract; I like that idea, although
I'm missing the "human readable" part there.

> I think values/amounts should be forced to (big) integers in APIs. The
> cent is actually the official unit of the USD.

Is it? AFAIK the "Dollar" stems from the "Thaler", which used to be a
Lot of silver, which is 1/30 or 1/32 of a pound = 1/2 ounce. These are
actually all weight measures, which makes perfect sense when trading
real assets. Only in the 1950ies was the paper "Dollar" re-defined by
law to mean "unit of paper issued by the FED" so that today it's a
"unit of digital bookkeeping that the issuing bank claims it can
exchange for units of thin air issued by the FED" :)

I think we should focus on creating a platform for a large set of all
kinds of different scenarios, including future ones that we might not
yet be aware of. From that viewpoint, forcing people with other
requirements to trade their assets in big integers is a restriction we
shouldn't really embrace. It's perfectly fine if org.leblue.cents is
traded in integers, and it's also ok to trade 5.32 com.goldmoney.aug ;
it's up to the individual issuer to define the smallest tradeable unit
of their asset. You could even trade 1000 org.leblue.cents for 5.32
com.goldmoney.aug.

Best,
A.

On 13 Aug., 04:27, Guillaume Lebleu <guilla...@lebleu.org> wrote:
> Several small thoughts.
>
> On assets vs units of value: I think we ought to distinguish units of
> account from assets. Checking money at a bank is an asset measured in
> units of USD, but it's not USD, just checking money issued by the bank
> convertible on demand in USD (Fed notes or Fed reserves on a Fed
> account), so the asset is bank.com/checking or com.bank.checking and

> the unit is USD. I don't recommend placing the unit in the URL (ex.http://bank.com/checking/USD). To go back to OpenTransact and banking/

> payment APIs in general, to me the URL points to the asset, but the
> response ought to provide the value and the unit, possibly multiple
> values in multiple units of value.
>
> On transactions: transfers within an asset should be very simple: ex.
> transfer from my checking to my savings or to my checking at bank.com/
> checking to my child's checking at bank.com. Payments on the other
> hand are much more complicated b/c they are typically meta-
> transactions, a series of balancing transactions each within a given
> asset, with one of them typically being two accounts at the Fed
> reserve.
>
> I think values/amounts should be forced to (big) integers in APIs. The
> cent is actually the official unit of the USD.
>
> Guillaume
>
> On Jul 22, 12:43 pm, Andreas Pizsa <hops...@gmail.com> wrote:
>
>
>
> > > I'm not sure about this yet. Might it be better to use an actual URI where
> > > you could go and get metadata about it?
>
> > Absolutely. Aren't naming and meta data location are two different
> > concepts? Naming would be a URN, while the whole Metadata Discovery
> > and Location stuff is XRI, as far as I understand it.
>
> > What I dislike about the URL solution is that it requires that the
> > location actually contains information about the asset class, which in
> > the cases of
>

> >http://bloomberg.com/bsym/EO1016052010040181900001http://bsym.bloombe...

> > > --http://agree2.com-ReachAgreement!http://stakeventures.com-Myblog about startups and agile banking

[Fellow Traveler]

On 8/23/10 2:07 AM, Andreas Pizsa wrote:

> Fellow Traveller suggests that the asset class identifier should be

> the hash of the actual securities contract; I like that idea, although

> I'm missing the "human readable" part there.

> 

Presumably the human-readable part would be one of the properties of the
contract. (Along with currency symbol, terms and conditions, redemption and liability, public keys, etc.)

When the wallet (or server) software loads the contract, it hashes the
contract to determine the contract ID.  It also loads the display name
out of the contract to list on the screen for the user.

In this way, you also guarantee a few things:

1) The ID will always be unique.
2) The ID will be consistent across all servers.
3) Changing the contract automatically changes the ID. (Software should
always hash the contract to verify the ID, and also verify the signature
on the contract using the public key inside of it.)
4) No need for a central "DNS server" for looking up the IDs based on
the names.
5) No ability for attacker to substitute a different contract.

This is not my idea btw, although I have incorporated it into Open
Transactions. (The "Ricardian Contract" was invented by Ian Grigg.)

-FT

[Guillaume P. Lebleu]

On Aug 23, 2010, at 3:50 AM, Fellow Traveler wrote:

> No need for a central "DNS server" for looking up the IDs based on
> the names.

Ok, but what about the reverse: given an asset ID, how do I locate the contract? or it this irrelevant in the OT world?

G

[Pelle Braendgaard]

A contract would more often (and practically speaking) be related to an underlying commercial provider. I don't think it needs to be part of the core transaction, but is part of the discovery process instead.

P

G

--
You received this message because you are subscribed to the Google Groups "agile-banking" group.
To post to this group, send email to agile-...@googlegroups.com.

To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.

--

http://agree2.com - Reach Agreement!

http://stakeventures.com - My blog about startups and agile banking

[Fellow Traveler]

On 8/23/10 11:14 AM, Pelle Braendgaard wrote:

> A contract would more often (and practically speaking) be related to an
> underlying commercial provider. I don't think it needs to be part of the
> core transaction, but is part of the discovery process instead.
>
> P
>
> On Mon, Aug 23, 2010 at 1:49 PM, Guillaume P. Lebleu
> <guil...@lebleu.org <mailto:guil...@lebleu.org>> wrote:
>
>
> On Aug 23, 2010, at 3:50 AM, Fellow Traveler wrote:
>
> > No need for a central "DNS server" for looking up the IDs based on
> > the names.
>
> Ok, but what about the reverse: given an asset ID, how do I locate
> the contract? or it this irrelevant in the OT world?
>
> G

Mr. Braendgaard is correct, IMO.

Presumably if you are transacting in a certain currency, then you have
already seen the contract, no? Or at least you have a good incentive to
have already seen it. This is true NO MATTER HOW you generate the
currency ID, whether it uses a message digest or a lookup server or
whatever.

In that case, where did you GET the contract in the first place?
The first, best place to get it is from the issuer himself. Maybe it's posted
on his website (it's signed.) So Open Transactions assumes first of all that
the primary source of the contract is the issuer himself.

You can STILL get the contract from a trusted 3rd party, via a DNS-style
lookup. While this sort of lookup is not necessary for OT to operate, it
IS necessary in the case of a REVERSE-lookup (as you describe.)

Assuming OT comes into regular use, more likely: aggregater websites
will appear, tracking the various currency contracts and providing
search functionality over them, just as torrent tracker sites operate
now for torrents. (There's no risk of forgery in these cases since the contract
is signed and self-authenticating.)

People are also free to try to keep certain contracts secret -- the system
operates fine without having to list them on any tracker site. But there's
nothing stopping people from putting up tracker sites, either. This is similar
to Loom I think.

-FT

[Anthony Di Franco]

On Thu, Aug 12, 2010 at 19:27, Guillaume Lebleu <guil...@lebleu.org> wrote:
> I think values/amounts should be forced to (big) integers in APIs. The
> cent is actually the official unit of the USD.
>
> Guillaume

Looking at this again, this does bear emphasis; amounts should be some
sort of integer or rational type and this should be strictly enforced.
I once had the displeasure of working with a large CRM/ERP package
that used floating point for amounts, leading to many obvious bugs
wherever equality was being checked, and others. People who should
have known better did not get this right on their own.

[Ryan Fugger]

This seems to me to be an implementation issue, not a protocol issue.
If the payment message says the amount is "43.234", then that's
well-defined. It's up to the implementation to decode it as a proper
decimal type and not floating point. I'm not sure insisting on
integer amounts only would make it any easier for the implementer who
has to deal with decimal amounts in the user interface.

I guess the desire to operate on integers only boils down to limiting
the number of digits permissible after the decimal point, since once
that's defined, any implementation can convert to integers if need be.
It might be useful to define this limit anyways, since
implementations shouldn't be expected to handle potentially
unlimited-length numbers. The limit should be fairly high though,
since some people might want to transact penny-value amounts in
kilograms of gold, for example, requiring something like 10 decimal
digits at least.

Interesting question.

Ryan

> --
> You received this message because you are subscribed to the Google Groups "agile-banking" group.
> To post to this group, send email to agile-...@googlegroups.com.

> To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.

[Guillaume Lebleu]

The currency contract should define the smallest (sub)unit available to use, and the implementation should enforce that in this unit, only integers are used. One way is to define the typical unit (ex. dollar) and the precision used in the currency contract (ex. 2 for cents). This is what I believe Trubanc does.

Currency contract aside, it's not a protocol/interface issue, I agree.

Guillaume

[Andrew McMeikan]

PKTP is guilty of floating point messiness, but it seemed the best
compromise. Internally floats are used storing grams of metal, with
user transacting in units from mg to kg, troy ounces or penny
weights. If it becomes a practical problem I will revisit it.

cya, Andrew...

[Anthony Di Franco]

I also agree that it is fundamentally an implementation issue rather
than an API issue, but the API can and should be designed to
discourage as much as possible bad implementations by using a
representation that is as close to the ones the range of good
implementations would be likely to use.
So, an unparsed string is worse than a pair of integer numerator /
denominator or integer digits / decimal place (scale) or an integer
amount + consistently defined implicit denominator.
Numerator / denominator would be the most flexible, integer digits /
decimal place would seem to be the closest fit to the common use case
of national currencies but may not work well for commodities or other
things.

[Anthony Di Franco]

If you do revisit the question, I found this to be good background:
http://speleotrove.com/decimal/decifaq.html

[Pelle Braendgaard]

Great link Anthony

--
http://agree2.com - Reach Agreement!

http://stakeventures.com - My blog about startups and agile banking

[David Nicol]

A little objectivity ...

On Mon, Aug 23, 2010 at 4:07 AM, Andreas Pizsa <hop...@gmail.com> wrote:

 

A com.bankofamerica.usd is something

entirely different than a gov.fed.usd and there should be mechanism on
the design level that makes such things transparent.

I object to "entirely" here. banking is strongly regulated to eliminate the risk, bankofamerica is more of a value-added reseller of usd than an independent issuer.

 

 

law to mean "unit of paper issued by the FED" so that today it's a
"unit of digital bookkeeping that the issuing bank claims it can
exchange for units of thin air issued by the FED" :)

I object to "thin air" here. I'm fond of saying that fiat currency is ultimately useful for paying taxes to the authority that fiatted it. I propose calling such things "units of thick air" as calling the dollars that we use regularly for groceries rent and bus fare "thin air" seems false by inspection. Submitted for your approval: thick air.

 

--
"Elevator Inspection Certificate is on file in the Maintenance Office"

[Pelle Braendgaard]

LOL I love it. Thick Air is great.

P

--
You received this message because you are subscribed to the Google Groups "agile-banking" group.
To post to this group, send email to agile-...@googlegroups.com.

To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.

--

http://agree2.com - Reach Agreement!

http://stakeventures.com - My blog about startups and agile banking

[Jae Kwon]

My 0.02 urn:x-asset:gov.us/USD...

There should be a (nominal) distinction between accounts and assets. In the bankofamerica example, com.bank.checking/<ACCOUNT_ID> is an account, so there is naturally no unit associated with it (unless we're talking about shares of an asset-backed account, but i don't think we are.)

Accounts could be denoted by urn:x-account:com.bank.checking/... etc. 

e.g. When you query my urn:x-account:com.bank.checking/12345 account, you'll see a map of asset->unit

    urn:x-asset:gov.us/USD -> 100.00

    urn:x-asset:gov.china/YUAN -> 10.00

What about asset classes with variable attributes? For example I may hold an asset that is redeemable for something else (like a certificate for gold or vegetables) but there may be limitations on when this asset can be redeemed. 

    urn:x-asset:com.premium-gold/1ounce?before=01-01-2011 could be an asset class that is redeemable for 1 ounce of gold at premium-gold.com, but only before 2011-01-01. 

There may be (many) other such variable attributes that may best be codified in the identifier of the asset class. For certificates to be redeemed for stored grain produce, there may be a variable demurral rate. 

    urn:x-asset:org.berkeley-coop-farms/1carrot?date=10-16-2010&<some parameters describing the demurral rate of this asset class that depends on the value of the 'date' parameter. >

Like so, I suggest that HTTP parameters be used to denote common parameters/variables of asset classes, if anybody felt the need for such a thing. 

 - J

[Anthony Di Franco]

Swamp gas, then.
The product of various unsavory processes that people generally don't
know about or like to think much about, leaves an oppressive stench in
the atmosphere wherever people are exposed to it, not the most elegant
way to get the job done, rather primitive, but not without its uses
despite all that.

On Wed, Aug 25, 2010 at 06:39, David Nicol <david...@gmail.com> wrote:
...

[Pelle Braendgaard]

That is definitely Thick Air LOL

--

You received this message because you are subscribed to the Google Groups "agile-banking" group.
To post to this group, send email to agile-...@googlegroups.com.

To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.

--

http://agree2.com - Reach Agreement!

http://stakeventures.com - My blog about startups and agile banking

[Andreas Pizsa]

> I object to "entirely" here. banking is strongly regulated to eliminate the
> risk, bankofamerica is more of a value-added reseller of usd than an
> independent issuer.

No one will disagree that banking is strongly regulated. When it comes
to eliminating risk though the question is whether any risk is
eliminated and if it is, what are the risks that are being eliminated
and to who's benefit.

Let me just focus on to the first two questions:

a) is a USD issued by Bank of America different from a USD issued by
the FED? and secondly,

b) is a risk is eliminated through regulation, specifically whether
there is any risk that a BOA USD can not be exchanged for a FED USD,
in other words, does regulation guarantee that there is a FED USD for
every BOA USD, so that BOA is a reseller for FED USDs and BOA adds
value to that FED USD.

b) is probably easier to answer, and will also answer a).

Regulation requires banks to keep only a fraction of their deposits on
reserve.

"The fact that banks are required to keep on hand only a fraction of
the funds deposited with them is a function of the banking business.
Banks borrow funds from their depositors (those with savings) and in
turn lend those funds to the banks’ borrowers (those in need of
funds). Banks make money by charging borrowers more for a loan (a
higher percentage interest rate) than is paid to depositors for use of
their money. If banks did not lend out their available funds after
meeting their reserve requirements, depositors might have to pay banks
to provide safekeeping services for their money. For the economy and
the banking system as a whole, the practice of keeping only a fraction
of deposits on hand has an important cumulative effect. Referred to as
the fractional reserve system, it permits the banking system to create
money."
http://www.federalreserveeducation.org/fed101/fedtoday/FedTodayAll.pdf

The important part to answer our question is the last sentence: the
banking system creates money ***that the FED did not issue***. There
are more units of credit in circulation than there are Federal Reserve
Notes issued (and I'm not taking into account now how FED notes get
created).

Now, how high is the minimum reserve requirement for banks? In the
US, it's 10% for transaction deposits and 0% (zero) for all others.
That means that banks can issue an effectively unlimited amount of
credit "notes" that are not backed by Federal Reserve Notes; in fact,
they are not backed by anything at all.

That answers b) pretty accurately: while the minimum cash reserve is
regulated, it's regulated to be zero. Does that eliminate the risk of
banks issuing more credit than they or the FED have deposits in
reserve? No; in fact, it *legalizes, by regulation* that banks can
create credit without any reserve deposits at all. That's a bit like
saying "alcohol consumption for minors is regulated", yet the
regulation sets the minimum age to 0.

This also answers a): is a USD issued by Bank of America different
from a USD issued by the FED?

Since BOA issues more USDs than they hold FED notes on reserve, and
every bank operates on the same terms, the amount of bank issued
"USD"s is a multitude of the quantity of money the FED issued *in
total*. Which is why there is no **guarantee** - and certainly not
through regulation - that everyone can redeem their BOA funds for FED
USD.

BOA is not a value added reseller; that would be like Amazon saying
"Thanks for your order, we keep the items on stock until you really
need them", yet when you actually demand shipment, they just can't
ship because they've sold way more items than have been produced, and
even more than can be produced in a thousand years. So is your claim
against Amazon different from the actual product? You bet it is,
especially if you've already paid them. And in the case that the fraud
is uncovered, regulation steps in and forces tax payers to pay the
bill.

I'm pretty surprised that at 12.9 trillion(!) debt* , anyone would
seriously argue that regulation reduces risk :) If 12.9 trillion isn't
severe risk, what is? :)

That's why asset classes are pretty crucial for a transparent
marketplace.

A.

* http://dekorte.com/blog/blog.cgi?do=item&id=4646

On 25 Aug., 15:39, David Nicol <davidni...@gmail.com> wrote:
> A little objectivity ...
>

> On Mon, Aug 23, 2010 at 4:07 AM, Andreas Pizsa <hops...@gmail.com> wrote:
> > A com.bankofamerica.usd is something
> > entirely different than a gov.fed.usd and there should be mechanism on
> > the design level that makes such things transparent.
>
> I object to "entirely" here. banking is strongly regulated to eliminate the
> risk, bankofamerica is more of a value-added reseller of usd than an
> independent issuer.
>
> > law to mean "unit of paper issued by the FED" so that today it's a
> > "unit of digital bookkeeping that the issuing bank claims it can
> > exchange for units of thin air issued by the FED" :)
>
> I object to "thin air" here. I'm fond of saying that fiat currency is
> ultimately useful for paying taxes to the authority that fiatted it. I
> propose calling such things "units of thick air" as calling the dollars that
> we use regularly for groceries rent and bus fare "thin air" seems false by

> inspection. Submitted for your approval: *thick air*.

[Jae Kwon]

> Now, how high is the minimum reserve requirement for banks? In the
> US, it's 10% for transaction deposits and 0% (zero) for all others.
> That means that banks can issue an effectively unlimited amount of
> credit "notes" that are not backed by Federal Reserve Notes; in fact,
> they are not backed by anything at all.

Reserve requirements apply only to transaction accounts, which are components of M1, a narrowly defined measure of money. Deposits that are components of M2 and M3 (but not M1), such as savings accounts and time deposits, have no reserve requirements and therefore can expand without regard to reserve levels. Furthermore, the Federal Reserve operates in a way that permits banks to acquire the reserves they need to meet their requirements from the money market, so long as they are willing to pay the prevailing price (the federal funds rate) for borrowed reserves. Consequently, reserve requirements currently play a relatively limited role in money creation in the United States. [http://www.newyorkfed.org/aboutthefed/fedpoint/fed45.html]

Yikes.

[Guillaume Lebleu]

In the case of OpenTransact, I believe the account ID is part of the OAuth credentials. I think there are cases where authorized users other than the account owners (ex. clerk) will want to perform operations, if only obtain the balance. This may justify the kind of standardized URL you recommend and a "to" parameter.

IMO, what you call variables should be part of the discoverable manifest of the asset, what Ian Grigg calls Ricardian Contract, not part of the request URL as it is something you accept, not something you request.  As in the case of options, a different exercise date implies a different asset ID, not a parameter of an asset class "option on asset  ID: X".

BTW, I'd like this Ricardian contract to be available in different representations (ex. POSH, JSON, XML, etc.), which means that if hashes are used as machine identifiers, they are done on the content only, not the whole message, so that the same hash can be obtained from different represenations.

G

[David Nicol]

On Thu, Aug 26, 2010 at 2:36 AM, Andreas Pizsa <hop...@gmail.com>

I liked the "debt is money" cartoon