Today's online payments mechanisms are reasonably effective, viewed in isolation.

Once cleared through banks, payments are reasonably final and nonrepudiable.  However, sending payments through banks is far from ideal, from the point of view of SMEs.  

• Automation of the payable and receivable process is broken because very little information other than the amount and date is transmitted by banks to the other party.  Financial institutions' needs to control their customer apparently prevents them from cooperating with each other or participating in generalized B2B integration involving customer identities, products, etc.
• Most banks provide limited access or views online -- online banking is usually limited to simple amount and date information, and lacks any programmatic interface other than high-end financial EDI.
• There is no assistance in bank reconciliation, and
• There is no assistance in reconciliation of AR and AP between trading partners, i.e. how a payment to a supplier might be recorded in the accounts payable. 

The account aggregation industry of course, such as Yodlee, has addressed some of these problems by building wrappers around banks, for benefit of users. But those aggregators are themselves portals and their B2B integration is still quite primitive. 

Today's practices in online sales on account are quite broken.  Very little credit is extended online, other than based on prior knowledge of the customer or expensive offline credit verification. There are two broad solutions for credit evaluation on the internet.  Centralized commercial credit scores, and some web of trust systems (1),(2),(3),(4),(5),(6). 

Internet-aware accounting systems could, in theory, change this picture completely.  The SME may, if they choose, provide information about their past transaction histories and dealings.  This information may be exposed to selected lenders or suppliers in order to gain favorable credit terms (such as accepting their PO!).  This information may be provided at extremely low cost since it could be automated by a webledger host, and the range of detail can be quite wide.  Technically, the veracity of entries in a GL could be confirmed by submitting queries to the reciprocal parties in each of the transactions upon which a reputation is based. 

The most basic reputation metrics available from a net accounting system may be computed as a single score, just as with commercial credit scores.  However, any general ledger visible on the internet could potentially provide  progressively greater views, beginning with the macro numbers comprising the reputation score (size, volume, timeliness, overall liquidity rating etc.)  CPAs are familiar with all of these classic measures such as working capital and liquidity measures.  A GL could go further to provide summary financial statements.  Complete  transaction detail may be presented to the supplier or creditor on a read-only basis.  This can be done on a masked basis concealing identities of customers, suppliers and products of the business. 

Today's banks continually put out the message that only the banking industry is capable of providing tomorrow's payments and settlements systems, because they are the only institutions having "trust".  One must inquire precisely what it is that SMEs need to "trust".   Most individuals and SMEs have high needs to trust institutions holding their savings assets, but 99% of the savings assets are invested in real performing assets, not in banks.  In  commercial dealings the requirement for trust is limited to knowing that the money is good.  In other words, if the money is good, online sales will be fulfilled.  Banks are under-performing on cost/performance in this key area.  Their activities are actually unhelpful and perpetuate a dumb, barefoot and pregnant existence for their depositors.

The importance of reputation in settlement

Banks, having decades of records of your deposits and withdrawals, are in a unique position to evaluate your credit. In effect, they have data objects representing your reputation.  The knowledge of reputation, including transaction histories themselves, are assets.  The economic reality of banks is only the aggregation of the reputations of other entities --their depositors and borrowers.

Reputation is rightfully, the property of the SME, not the bank.  It is the goal of arapXML to design XML schemas that represent broadly agreed measures of reputation, and enable the SME to encapsulate their reputation in XML schemas.  In effect, we are breaking out of the portal control by banks, by stealing our reputations back from them.  We are going to maintain our own reputations, thank you.

The accountancy industry, like the banks, would also like to sell your reputation back to you. If certified  accountants had their way, the credibility of all financial statements would be precisely zero until they were  inspected by accountants.  As with the banks, the key to empowering SMEs is empirical, factual data from the web of transactions they execute with third parties.  Financial statements comprised entirely of transactions executed in arms length dealings with third parties, and verifiable by any reviewer, will reduce the need for recharacterization of all SME's business transactions into the formats required by the SEC and accountancy profession.  

In settlement, the only thing that matters to SMEs is whether their customer's money is good.  In credit, likewise, the only thing that matters is whether the customer's reputation is good.  Within a net accounting universe these are a matter of empirical facts, derived from actual transaction histories maintained on servers.

Example of empirical ledger reputation

Imagine the approaching era, when computers and devices are better-hardened, and strong authentication solutions exist such as Liberty Alliance or MeT devices, is widespread.  

Imagine a small business wanting to sell to a potential customer, either at less cost than credit cards, or to gain increased sales on credit.  For whatever reason, the seller is considering direct AR/AP relationship, to be settled later by settlement agents within an AR/AP cloud, and the buyer has significant motivation to want to buy on credit. For example, the business might be trying to sell automobiles or other difficult merchandise. 

Buyer:  "Prove your credit is good." 
Seller:  "Here are some credit references and contacts within the Greater Podunk reputation club." (sends URLs and encrypted identity tokens for 30 business relations.)
Buyer:  (polls the 30 servers. 5 are offline and 25 agree, yes, we know that guy and we signed those tokens.) "OK that's impressive but what kinds of dealings did you have? " 
Seller:  (sends a listing of the total purchases in the last 12 months from those 30 companies, together with URLs and encrypted transaction tokens.)
Buyer:  (polls those servers.  25 agree, yes, we know that guy and we signed those YTD sales amounts.) "OK that's impressive but show me your balance sheet. "
Seller: (Sends trial balance in ArapXML format.)
Buyer: (drills down on Cash account by invoking the ARAP account interface.)
Seller: (Blocks drilldown)
Buyer  "Well, ok let me see your cash, receivables etc."
Seller: "OK try again" 
Buyer: (drills down on Cash account)
Seller: (clicks OK on dialog box)
Buyer: (drills down on Accounts Payable, drills down on the biggest debt, etc.)....

This is clearly, not a dialog everybody will be willing to participate in, at first.  But once people get used to the idea, it really is not that far fetched.  Any banker or CPA will recount numerous engagements, the purpose of which was to "go over the books" of some party to determine creditworthiness.  When a buyer wants credit, they are quite often willing to reveal some or all of the history of their dealings. 

To prepare for the above scenarios, accounting systems would generate a token for every transaction executed with trading partners, and offer it to their trading partner at time of the transaction.  Thereafter, the trading partner or his delegatee could fetch that transaction at any time in the future.  A simple idea, and one which is necessary in some form, for automated AR/AP reconciliation.

To enter a reputation club, a new member would import their data into a reputation-capable ledger, and generate tokens for all historical transactions.  The accounting system would advertise to all trading partners the availability of these tokens.  These are after all, transactions that each of those trading partners was a party to. 

Some trading partners will be unable or unwilling to respond to reputation queries (credit checks) from 3rd parties.  That will be fine.  Their reputations will be lowered by others in the community.  No big deal.  

Some trading partners will object to anybody disclosing their deaings to anybody outside the original buyer-seller relationship.  Nevertheless, it is already a legally established right and a common practice, which already inherent in all banking and extension of credit. The principle difference is that with webledger reputation mechanisms, these disclosures are to benefit the owner, broadening his choices of lenders rather than financial institutions.   In any case, these objectors will repudiate verification inquiries thus, making the dealings less likely to be used by anybody trying to get credit to buy used cars! 

Empirical reputation scores from webledgers will be very reliable predictors of creditworthiness.  It will be very difficult to quickly create a false identity or presence that generates good reputation scores.  It is implausible, for example, that a lot of fake companies could be established with fictitious mutual trades because the absences of trades with other communities would be observed by the webledger host.  Lucas Gonze, developer of WorldOS and authors in web of trust, has observed that false nym associations are apparent even without the power of a shared transaction host; "...The cost of doing business for all of those thousand fictitious characters would outweigh the value of a possible con."

Reputation schemas for mutual AR/AP systems and for webledger hosts, are in draft stage. There will be progressive levels of reputation, on a quantitative scale ranging from simply knowing of the existence of other nodes for periods of time, thru complete drilldown.  Empirical reputation is closely connected with vocabulary for querying accounting details, aggregates and financial ratios, which is not yet complete for ArapXML. 

home

Top down (external) systems of reputation evaluation
-- Credit Agencies
-- Banks 
-- Auditors

Peer systems – SMEs vet for each other
-- “web of trust” an old idea

Empirical reputation metrics
-- automated calculation of reputation scores
-- like eBay
-- like U.S. numerical credit scoring systems
-- except, each party generates it for themselves
-- naming their trading partners as proof if necessary
-- enumerating their past transactions as proof

Webledger reputation metrics
-- calculated by a webledger host, based on history.
-- disclosure to 3rd parties is controlled by Owner's decisions.
-- progressively from zero to highly private information.
-- the recipient gets a technical reliability from the Host.
-- eliminates some degree of wholesale fraudsters.

Hosts can compute reputation scores without revealing any detailed
private information, based on

-- member's length of time on the host service.
-- number and value of transactions with other members, by period.
-- whether trading partners have complained.
-- your outstanding debt, financial ratios, current assets, cash,
etc. in your accounting system
-- whether those accounting entries are audited.
-- whether this is your master GL or just a sub-ledger or segment
of your business.
-- balance and transaction information available to the
webledger by querying your bank.
-- types of those accounts; including escrow or collateral in
ARAP settlement agents or schemes.
-- numerous other objective facts.

Any sovereign individual or company can evaluate the creditworthiness of 
entities it encounters on the internet, by conducting analytical 
procedures and queries and applying formulas to the results. 

Traditional procedures that can be mostly automated now, include

-- get the entity's real, civil identity. 
-- obtain conventional credit scores if the trade is high value. 
-- obtain whatever information is available from free search 
engines and directories, establishing the identity facts
like length of time at present address, etc. 
-- ask the party for information (i.e. a credit application)

New procedures depend on the partner, and his trading community,
adopting new behaviors: 

-- each peer must maintain some basic, public query interfaces
-- each peer must be capable of returning at least minimal 
reports about its experience with other peers. 
-- the "facts" reported by any entity must be cryptographically
confirmable by entity it names as having done business with.

-- any peer seeking empirical reputation facts must have software
capable of composing the foundation queries to its debtor, 
and understanding the replies.
-- the peer must then be capable of forming valid queries and
submitting them to the "references" parties named in the 
foundation query. 
-- therefore, a shared vocabulary for describing transactions, 
and aggregates of transactions such as balances, is required.
-- and, a set of methods, for query/response, is required. 
-- drilldown from account totals into detailed transactions,
would ultimately be required. 

-- almost everything else is private, i.e. analytical models 
of lenders will be proprietary and competitive.

-- sovereign parties may also publish empirical reputation scores
just as if they were a webledger; . 
-- sovereign parties may get their own credit histories from
Equifax, Experian etc. and publish those to lenders. 
-- sovereign parties may appoint attorneys to get credit histories.
-- an attorney may digitally sign a credit history.
-- a sovereign party may make those credit histories them available 
to lenders (credit'ster.)