When a user of TBDex wants to obtain financial data such as his account and routing number, transaction history or balance to apply for a loan or to buy or sell bitcoin an API that can provide the data automatically, without copy/paste error and signed as accurate is usually the preferred option.
When more than one option exists to obtain a VC with the required financial data the hub should select the provider without asking the user. This is to optimize the user experience (and because the user rarely has the information required to make an informed selection).
When more than one provider is available the selection criteria should be:
Privacy - Some providers resell the financial data or store it for long periods. Other providers are third parties (they are not the data source, but are intermediaries that screen scrape the data or call the data source’s API and then issue a VC) that must access the data on behalf of users, but are contractually obligated to delete the data and never reuse it.
Speed - Some services are faster than others and the speed can range from a few milliseconds to over 3 minutes among providers.
Cost - Some providers have an annual minimum payment in the tens of thousands of dollars with a per connection fee at over a dollar each. Other providers do not have annual minimums and charge only 1,000 satoshis per API call.
Accuracy - Financial data is often inaccurate or missing. For example obtaining the full account number more than 90% of the time or obtaining more than 90 days of transaction history is still a significant selling point among financial data providers as of 2022.
The identity hub reference implementation should include a simple algorithm to select a VC issuer. It should be easy to understand and modify to reflect their particular use cases and target users of a specific implementation.
One option is to assign an arbitrary number of points to privacy, speed, cost and accuracy that are then multiplied by the provider's score in each of these areas.
Let's call these priority points and assign an arbitrary value to each.
Default Priority Points:
Privacy - 12 priority points
Speed - 7 priority points
Cost - 14 priority points (with a maximum cap to default to 10,000 sats)
Accuracy - 9 priority points
This means that if provider A has excellent privacy but is very slow, cheap and accurate it would be awarded 12+0+14+9 = 34 points. If provider B has poor privacy, but is very fast, cheap and accurate it would be awarded 0+7+14+9 = 30 points. As a result provider A would be selected over provider B in this example.
Since providers are usually not either 100% good or bad in these areas we can assign them an arbitrary number of points based or their self reported behavior (although as with accuracy a better mechanism for obtaining this data should be considered an open work item):
Privacy:
Original data source without any third parties accessing the data - 100 privacy points.
Third party without access to credentials, with access to data but is contractually obligated to immediately destroy all copies - 90 privacy points.
Third party with access to credentials and data, but is contractually obligated to immediately destroy all copies - 80 privacy points.
Third party without access to credentials, with access to data and is not obligated to immediately destroy all copies - 30 privacy points.
Third party with access to credentials and data that is not obligated to to immediately destroy all copies - 0 privacy points
Speed:
0-10 seconds - 81 to 100 speed points
11-30 seconds - 80 to 61 speed points
31-90 seconds - 60 to 41 speed points
91-120 seconds - 40 to 11 speed points
121 - 200 seconds - 10-1 speed points
Over 200 seconds - 0 speed points
Cost:
0 - 1,000 sats 100 cost points
1,001 - 4,000 sats 60 cost points
4,001 - 10,000 sats 20 cost points
Over 10,000 sats - 0 cost points
Accuracy:
This is a difficult criteria because it is specific to a given financial institution and data field. For example a provider might retrieve the account number from Chase 99.999% of the time, but obtain the routing information only 10% of the time.
For now this can be treated as an open work item as initially there will not be many cases where more than one provider is available for a given financial institution and the subset where data accuracy would be the deciding factor is approaching zero, but the ideal solution is for wallets to report success rates over time so that they can be used to route requests.
Example Calculation
Let's assume provider A is a third party that does access user credentials and data, but is contractually obligated to delete all data (80 privacy points), will take 20 seconds to retrieve the data (70 speed points) and charges 1,000 sats (100 cost points).
To convert from privacy, speed and cost points to selection points we multiply the two numbers
Privacy - 12 priority points
Speed - 7 priority points
Cost - 14 priority points (with a maximum cap to default to 10,000 sats)
80 (privacy points) * 12 priority points = 960 selection points
70 (speed points) * 7 priority points = 490 selection points
100 (cost points) * 14 priority points = 1400 selection points
With a total of 2850 selection points provider A will be chosen when the alternative providers have fewer than 2850 selection points.
This was briefly discussed with @csuwildcat on a call last week.