- From: Joseph Potvin <jpotvin@opman.ca>
- Date: Wed, 4 Jun 2014 06:58:00 -0400
- To: Dave Lampton <dave.lampton@gmail.com>
- Cc: Web Payments CG <public-webpayments@w3.org>
- Message-ID: <CAKcXiSoDQ4uq05_uyiJ0jMP=QrR5Rj84vkcuZ0OBiAYdfdVP6Q@mail.gmail.com>
During the period of the payment, surely. And then... what's the expected persistence of the information in a digital wallet? Joseph On Wed, Jun 4, 2014 at 6:47 AM, Dave Lampton <dave.lampton@gmail.com> wrote: > Intentionally NOT keeping track of any accumulated "quantified > entitlements & obligations" over time. > > > Dave Lampton > * @dave_lampton <https://twitter.com/dave_lampton>* > > * DaveLampton <https://www.facebook.com/DaveLampton> +DaveLampton > <https://www.google.com/+DaveLampton>* > www.linkedin.com/in/davelampton/ > > > > > On Wed, Jun 4, 2014 at 3:45 AM, Joseph Potvin <jpotvin@opman.ca> wrote: > >> Dave, Define "simple". >> >> Joseph >> >> >> >> >> On Wed, Jun 4, 2014 at 6:34 AM, Dave Lampton <dave.lampton@gmail.com> >> wrote: >> >>> Thanks Joseph, lots of good stuff to read. >>> >>> In the case of my little proof of concepts system... I just want to keep >>> things literally as simple as possible so I'm ignoring the concept of >>> "quantified entitlements & obligations", and only dealing with the >>> real-time transfer of already possessed "digital cash" between any two >>> parties that have control of compliant "wallets"/"accounts". >>> >>> >>> Dave Lampton >>> * @dave_lampton <https://twitter.com/dave_lampton>* >>> >>> * DaveLampton <https://www.facebook.com/DaveLampton> +DaveLampton >>> <https://www.google.com/+DaveLampton>* >>> www.linkedin.com/in/davelampton/ >>> >>> >>> >>> >>> On Wed, Jun 4, 2014 at 2:45 AM, Joseph Potvin <jpotvin@opman.ca> wrote: >>> >>>> Dave, >>>> >>>> For further reflection, see work by Geoffrey Ingham, since it matters >>>> "what" we're speaking about sending around when discussing a payments >>>> system. >>>> >>>> http://ca.wiley.com/WileyCDA/WileyTitle/productCd-074560997X,subjectCd-EC06.html >>>> >>>> http://cas.umkc.edu/econ/economics/faculty/wray/601wray/Ingham_ontology%20of%20Money.pdf >>>> http://www.twill.info/the-ontology-of-money/ >>>> http://www.palgraveconnect.com/pc/doifinder/10.1057/9781137302953.0007 >>>> Sample chapter http://www.palgrave.com/PDFs/9781137302946.pdf (The >>>> book was edited by my former thesis supervisor Geoff Harcourt. After the >>>> Paris workshop in April I travelled over to Cambridge UK to discuss some of >>>> the issues of payment with Ingham. >>>> >>>> The link I provided in another thread to an UNCITRAL document is well >>>> worth reading, to consider the significance of registry-based versus >>>> token-based ways of sending around the quantified entitlements and >>>> obligations that Ingham speaks of: >>>> http://www.uncitral.org/pdf/english/workinggroups/wg_4/wp_119_e.pdf >>>> >>>> For example, ACH (Automated Clearing House) is registry-based. BTC is >>>> token-based. XRP is token-based. >>>> >>>> I came to the conclusion that the only legitimate "value" of 1 BTC is >>>> zero. BTC is merely the message-bearing token, it's not an instantiation of >>>> "the value". It's limited supply is meaningless. For this reason I agree >>>> with the determination of courts in Finland, China and elsewhere that BTC >>>> is a digital commodity, a sort of electronic vehicle to transport >>>> information about the quantified entitlements and obligations that Ingham >>>> speaks of. A unit of BTC is therefore properly worth no more than the >>>> scanned image of a paper cheque. That scanned image is worth zero, and >>>> cannot be logically conflated with the value being exchanged. >>>> >>>> Some consider these matters "too academic". My response is that if what >>>> we were talking about was the development of standard specifications for >>>> international shipping containers, it would not be "too academic" to >>>> determine whether these containers had to be suitable to ship things like >>>> fresh tomatoes as well as steel bars. It matters just as much what this >>>> "web payments" system is supposed to be shipping around. >>>> >>>> -- >>>> Joseph Potvin >>>> Operations Manager | Gestionnaire des opérations >>>> The Opman Company | La compagnie Opman >>>> jpotvin@opman.ca >>>> Mobile: 819-593-5983 >>>> >>>> >>>> On Wed, Jun 4, 2014 at 12:07 AM, Dave Lampton <dave.lampton@gmail.com> >>>> wrote: >>>> >>>>> Hi Tim, the speech was the one Joseph had sent a link to previously: >>>>> http://www.richmondfed.org/press_room/speeches/president_jeff_lacker/2011/lacker_speech_20110907.cfm >>>>> >>>>> I guess I am fundamentally dissatisfied with credits or IOUs. I want a >>>>> real currency backed by a central bank that I can give to anyone I want to, >>>>> instantly, without a third party - just like I can do with cash today. >>>>> >>>>> btw, for the record, the idea that nothing is 100% secure... well, >>>>> that's the common thought, but when used properly there are some schemes >>>>> that actually do guarantee secrecy. A One-Time Pad >>>>> <http://en.wikipedia.org/wiki/Vernam_cipher> being an example. >>>>> >>>>> For the system of "digital money" I am putting together, however, I've >>>>> turned things upside down to avoid the burden of keeping everything secret. >>>>> I'm developing a simple security system that does NOT rely on encryption to >>>>> provide secrecy, but instead uses it identify and report on data that will >>>>> be widely shared public information instead. >>>>> >>>>> >>>>> Dave Lampton >>>>> * @dave_lampton <https://twitter.com/dave_lampton>* >>>>> >>>>> * DaveLampton <https://www.facebook.com/DaveLampton> +DaveLampton >>>>> <https://www.google.com/+DaveLampton>* >>>>> www.linkedin.com/in/davelampton/ >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Jun 3, 2014 at 8:28 PM, Tim Holborn <timothy.holborn@gmail.com >>>>> > wrote: >>>>> >>>>>> Hi Dave, >>>>>> >>>>>> Do you have a Link to the speech you refer to? >>>>>> >>>>>> (draft, i still have a great deal more to author, before editing… - >>>>>> but link: http://webarts.mediaprophet.net/?page_id=39 ) >>>>>> >>>>>> Personally; i agree that individuals should have their own domain >>>>>> names; and that whilst this is not and should not be a mandatory >>>>>> requirement for users, the ability to use existing WWW Systems (inc. DNS) >>>>>> with a domain provides enormous benefits. Perhaps the barrier is the >>>>>> methodologies in which existing CPANEL (or similar) systems work; and >>>>>> within that environment, webized [1] Cloud Storage [2] provides some of the >>>>>> underlying building blocks needed to create cloud-based user-environments, >>>>>> supporting an array of WWW applications… >>>>>> >>>>>> deiu wrote a paper [3] relating to his work on RWW.io / data.fm and >>>>>> related Linked Data [4] projects (of which deiu is involved…). Obviously, >>>>>> members encourage others to develop solutions in an array of ways, from >>>>>> use-case and standards; to working solutions. I think the main effort >>>>>> surrounds attempting to collaborate around the standards needed to support >>>>>> interoperability, supporting users through web-standards as best as >>>>>> possible. >>>>>> >>>>>> In your text, you’ve embedded a few economic models around how you >>>>>> envisage your service to be commercialised. Classical Web 2 models >>>>>> centralise data to a branded domain where CDN’s and related infrastructure >>>>>> then need to support user-growth. revenue models in-turn are supported >>>>>> often, by systems such as advertising and data-mining. Due to the nature >>>>>> of a centralised or funnel styled topology, the bulk of users are then >>>>>> served by a centralised management system that can support sophisticated >>>>>> internal business units, in-turn supporting commercial engagement with >>>>>> vendors supporting functions such as advertising aggregation and >>>>>> monitization. >>>>>> >>>>>> In distributed models - users would have their own accounts and their >>>>>> own hosting space. Perhaps some systems are sold / purchased / leased by >>>>>> the user on the basis of an economic awareness surrounding the use of >>>>>> advertising systems to make the cost to the user, of owning a service - >>>>>> cheaper or free. Ideally perhaps, these systems can be as cheap as is >>>>>> possible whilst also being highly secure - so that more sensitive data such >>>>>> as commercial objects, personal objects of a sensitive nature (medical >>>>>> records, financial accounts, etc.) are entirely secure save exceptional >>>>>> circumstances where a court-order may require disclosure on a specified >>>>>> account, or similar… >>>>>> >>>>>> anything that is 100% secure - actually doesn’t exist, from thereon >>>>>> its’ a slippery slope and i guess the gambit is to get close to that >>>>>> rating, without engaging in a conversation with those who believe they can >>>>>> obtain it. >>>>>> >>>>>> Another up-side of distributed applications, is that application >>>>>> developers do not need to fund the traffic requirements for growth. This >>>>>> in-turn democratises the capacity to build applications, and to >>>>>> successfully commercialise them, similar to the old industry of >>>>>> distributing open-source software on floppy disks / early internet systems. >>>>>> >>>>>> >>>>>> IMHO, it gets down to a philosophical layer, which i think is best >>>>>> described here [5]. If, as a community, we build standards and basic >>>>>> systems that support the needs of a person (natural legal entity); then the >>>>>> rest benefits, including our ability as persons to develop applications >>>>>> that we believe have a role to play in life, in some practical sense. It >>>>>> seems sensible to consider that Web2 portals will develop technologies to >>>>>> adapt their service to improve functionality, and support web3 >>>>>> capabilities. meanwhile new applications will develop using web3 >>>>>> functionality, requiring some form of cloud-storage that may or may not be >>>>>> hosted by a person on their own domain… >>>>>> >>>>>> I’m not sure how many people in future will store all their digital >>>>>> transaction receipts in Facebook, or on a google, iCloud or similar service >>>>>> - but i’m sure they’d all hope for millions… Equally, i believe >>>>>> individuals may benefit from the transparency and ease of understanding the >>>>>> data-privacy related risks incumbent upon the alternative of storing all of >>>>>> your personal data, on your own hosting system, connected to your own >>>>>> domain, using your own run-time of software solutions that incorporate a >>>>>> ‘data space’ as something that is owned by you legally, as it is connected >>>>>> to that specified domain of which you are responsible for its operations; >>>>>> or something along those lines… >>>>>> >>>>>> underlying that of course; is the need for security with regard to >>>>>> fiduciary responsibilities. AML, KYC are amongst the terms used in this >>>>>> space. I would argue that if a user has an institutionally approved Cloud >>>>>> Storage service (as described, in-part, by the references in this doc); >>>>>> then so long as a transaction is between two known entities; facilitated in >>>>>> a manner that maintains integrity between WWW Points of distribution >>>>>> (meaning, from one person to another person, without being intercepted, >>>>>> copied, redirected, etc.) then in-turn institutional systems should be able >>>>>> to honour those ‘IOU’s’. >>>>>> >>>>>> Whilst some may argue that users storing their own data is insecure; >>>>>> i’m aware of local police departments in countries other than the USA >>>>>> having difficulty accessing data from portals owned, operated & >>>>>> incorporated in the USA for good purpose. Perhaps two imaginary examples >>>>>> could be 1. like kids, publishing or promoting their suicide intentions, >>>>>> being ‘missing’ from loved ones at the time or 2. person gets into car >>>>>> accident and the emergency department has difficulty obtaining health data >>>>>> / records from the individuals mobile-phone application package provider, >>>>>> who delivers the application freely with advertising... >>>>>> >>>>>> I’ve started putting together documentation for my mid-year update; i >>>>>> know a bunch of typo’s, issues exist - am still working on it..); >>>>>> nonetheless, >>>>>> >>>>>> hopefully useful... >>>>>> >>>>>> What are WebCredits - http://webarts.mediaprophet.net/?page_id=39 >>>>>> GraphDB Technology vs. relational Databases - >>>>>> http://webarts.mediaprophet.net/?page_id=52 >>>>>> Socio-economics and the evolution of relational database technology - >>>>>> http://webarts.mediaprophet.net/?p=63 >>>>>> Don’t be afraid of ‘peer to peer’ - >>>>>> http://webarts.mediaprophet.net/?p=61 >>>>>> (any suggestions on my works, always welcome ;) ) >>>>>> >>>>>> [1] http://www.w3.org/DesignIssues/Webize.html >>>>>> [2] http://www.w3.org/DesignIssues/CloudStorage.html >>>>>> [3] http://myprofile-project.org/thesis/manuscript_en.pdf >>>>>> [4] http://github.com/linkeddata/ >>>>>> [5] http://www.w3.org/2007/09/map/main.jpg >>>>>> On 4 Jun 2014, at 1:54 am, Dave Lampton <dave.lampton@gmail.com> >>>>>> wrote: >>>>>> >>>>>> Not sure exactly what to make of the Lacker speech. He's still >>>>>> talking present day technologies with middle-men and discussing the >>>>>> perceived usefulness of trying to minimize transaction times to reduce >>>>>> float. I'm talking about negating the float altogether by allowing >>>>>> individuals to trade real digital currency, just like we can trade real >>>>>> physical currency without a middle man today. >>>>>> >>>>>> My concepts are akin to a peer-to-peer payment system with real-time >>>>>> clearing from the central bank of that currency. Similar to the Web Credits >>>>>> idea, having a "wallet" (or an "account" or a "generic money bag" etc.) at >>>>>> a particular URI is part of my thinking as well, however I have the >>>>>> software endpoints much more concretely defined to a standard. In my >>>>>> imagined system we'd actually be trading REAL dollars (or yen or francs or >>>>>> whatever that central bank issues) and the central bank clears transactions >>>>>> on its own currency in real time. Every digital dollar will always have a >>>>>> single "physical" home (an obfuscated URI) at any one time. Payers initiate >>>>>> transactions. Cost would be on the order of $10 to run a server like this >>>>>> for a whole year. There would be almost no cost to anyone who maintains >>>>>> their own currency server (just electricity and an Internet connection). >>>>>> The cost of maintaining a single server would be comparable to having an >>>>>> email server, to the point that it's likely people would be giving away >>>>>> these accounts as part of a loss-leader to upsell to some other service >>>>>> perhaps. >>>>>> >>>>>> Anyway, I know, I'm still just the new guy here... :) >>>>>> so I say it all with some humility... >>>>>> ...but I feel like I have yet to see a proposed system that does >>>>>> everything mine does. I guess I should try to find time to finish a working >>>>>> demo of it. I'm about a third of the way there already. >>>>>> >>>>>> Cheers. >>>>>> >>>>>> >>>>>> >>>>>> Dave Lampton >>>>>> * @dave_lampton <https://twitter.com/dave_lampton>* >>>>>> >>>>>> * DaveLampton <https://www.facebook.com/DaveLampton> +DaveLampton >>>>>> <https://www.google.com/+DaveLampton>* >>>>>> www.linkedin.com/in/davelampton/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jun 3, 2014 at 8:21 AM, Timothy Holborn < >>>>>> timothy.holborn@gmail.com> wrote: >>>>>> >>>>>>> Re: dave's post below... >>>>>>> >>>>>>> Webcredits is an alternative that seems to provide a functionally >>>>>>> similar capability (although, using rww systems), with an array of other >>>>>>> functional capabilities. >>>>>>> >>>>>>> See #webcredits in freenode, or >>>>>>> http://www.w3.org/community/webpayments/wiki/Web_Credits >>>>>>> >>>>>>> If you get a rww.io or data.fm account, and put a Testnet address >>>>>>> into your foaf document, I think melvster (in #webcredits, per above) has a >>>>>>> bot running that can provide some basic demonstrations. >>>>>>> >>>>>>> His also a walking library of knowledge in that area specifically.... >>>>>>> >>>>>>> Mind. Accelerating, and diminishing costs for transfers is one >>>>>>> thing. I figure once a transaction hits a financial bank to be converted >>>>>>> into traditional currency, it'll likely have requirements surrounding >>>>>>> identifying where the funds are sourced, etc. >>>>>>> >>>>>>> Much like existing payee relationships, once one payment has been >>>>>>> made between two accounts, additional transactions are easier. >>>>>>> >>>>>>> This is perhaps different for digital currencies, or IOU's / >>>>>>> accountability capabilities, and other purposes of stuff like block-chains, >>>>>>> and things that can be done with that geek... >>>>>>> >>>>>>> I don't think gold needed an identity, beyond being tested to ensure >>>>>>> it was gold. The ID has always lived with the accounts systems. Perhaps >>>>>>> also ensuring people don't taint the "gold" with a cheaper substitute, or >>>>>>> otherwise breach the terms of trade. More complex examples could be >>>>>>> asserting a value for use of an image, beyond the scope of a Creative >>>>>>> Commons license, perhaps all embedded in the image... The semantic >>>>>>> clipboard http://dig.csail.mit.edu/2009/Clipboard/ seems to >>>>>>> consider the Creative Commons elements quite well... >>>>>>> >>>>>>> Webcredits is well worth a look IMO... I'm really impressed with >>>>>>> it, understanding of course, it's still early days... >>>>>>> >>>>>>> Timh. >>>>>>> >>>>>>> Sent from my iPad >>>>>>> >>>>>>> On 4 Jun 2014, at 1:00 am, Joseph Potvin <jpotvin@opman.ca> wrote: >>>>>>> >>>>>>> Dave, >>>>>>> >>>>>>> Take a look at "Immediate Funds Transfer: A Central Bank >>>>>>> Perspective" from the Federal Reserve Bank of Richmond >>>>>>> >>>>>>> http://www.richmondfed.org/press_room/speeches/president_jeff_lacker/2011/lacker_speech_20110907.cfm >>>>>>> >>>>>>> http://www.chicagofed.org/webpages/publications/economic_perspectives/2011/summers_wells.cfm >>>>>>> >>>>>>> -- >>>>>>> Joseph Potvin >>>>>>> Operations Manager | Gestionnaire des opérations >>>>>>> The Opman Company | La compagnie Opman >>>>>>> jpotvin@opman.ca >>>>>>> Mobile: 819-593-5983 >>>>>>> >>>>>>> >>>>>>> On Tue, Jun 3, 2014 at 10:50 AM, Dave Lampton < >>>>>>> dave.lampton@gmail.com> wrote: >>>>>>> >>>>>>>> Since its inception, PayPal has primarily made their money "on the >>>>>>>> float" meaning that during those few days they have your money, they are >>>>>>>> able to invest it in short-term money markets, etc. When you're dealing >>>>>>>> with such a large number of transactions, these investments can be very >>>>>>>> large and the returns quite handsome. >>>>>>>> >>>>>>>> I'm new to this group, but I have joined because I've been >>>>>>>> developing my own solutions for "digital money" and wanted to see what else >>>>>>>> is going on. So far, I am gathering that both the current WebPayments >>>>>>>> (PaySwarm) platform as well as other proposed alternatives like >>>>>>>> OpenTransact are still all based on email for the sending/receiving of >>>>>>>> payments, is that right? >>>>>>>> >>>>>>>> There is STILL no way for me to send $5 directly to my brother, for >>>>>>>> example. There is still always going to be at least one third party >>>>>>>> involved, and often more than one, just for me to give my brother five >>>>>>>> bucks. Or have I missed something? >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> Has anyone discussed the development of something entirely new like >>>>>>>> a protocol especially used for nothing but financial transactions? My >>>>>>>> feeling is that email servers don't know what a payment is and never will >>>>>>>> be able to do anything with one. End users are still dependent on a >>>>>>>> third-party to move money to/from their bank accounts. >>>>>>>> >>>>>>>> On the other hand, I have a much more complete system for digital >>>>>>>> money developed in my mind if anyone is interested. If our money were held >>>>>>>> by our own digital accounts, we could send money to one another just like >>>>>>>> we can already hand one another cash without any third-party involvement. >>>>>>>> (it would even put into question the need for banks!) A super brief >>>>>>>> overview follows: >>>>>>>> >>>>>>>> First off, this idea would actually require governments/central >>>>>>>> banks to issue the digital currency that could subsequently only live in my >>>>>>>> proposed digital accounts. Yes, I realize that's a huge hurdle to expect >>>>>>>> their involvement at any stage, but frankly, I think it is the only real >>>>>>>> way to solve the larger problems permanently. >>>>>>>> >>>>>>>> So, what if every financial account in the world were assigned a >>>>>>>> permanent URL (either a domain or subdomain that is owned by the account >>>>>>>> holder). Every website already requires a domain, so it's not a big leap to >>>>>>>> require every digital account to also have a domain or subdomain (and with >>>>>>>> the advent of IPv6 we'll have so many IP addresses at our disposal, it's >>>>>>>> absurd). Ownership of digital accounts and the transfer of their ownership >>>>>>>> would all be handled using the same mechanisms we use today to manage >>>>>>>> domains using registrars and DNS. In this case, every digital dollar must >>>>>>>> have a home in a digital account somewhere. Each digital dollar knows its >>>>>>>> issuing bank, its unique serial number, its current owner (holding account) >>>>>>>> and >>>>>>>> >>>>>>>> Essentially, a digital account would be a new type of Internet >>>>>>>> endpoint, one that is similar to the function of an email server, but only >>>>>>>> processes financial transactions. It would be addressed in much the same >>>>>>>> way that email servers have an MX record in DNS, the currency servers might >>>>>>>> have a CX record. In my mind, the easiest way to implement something like >>>>>>>> this would be with a Node.js server using secure WebSockets (wss://) and a >>>>>>>> simple NoSQL document store, most likely a MongoDB instance. The software >>>>>>>> itself could be so simple as to be mindless, not even needing >>>>>>>> configuration, knowing only how to either send or receive currency, nothing >>>>>>>> more. >>>>>>>> >>>>>>>> Lastly, my ideas to keep it all secure turn the traditional >>>>>>>> cryptographic methods upside-down. Rather than make every financial >>>>>>>> transaction in the world a big freakin' secret, I would instead make every >>>>>>>> transaction completely public and recorded by a whole lot of people at >>>>>>>> once. It would be impossible to fake because only the central banks will >>>>>>>> transmit transaction confirmations, but everyone will be keeping copies of >>>>>>>> them as they happen on their network segments, and records can be looked up >>>>>>>> by anyone at any time. However, to be fair to everyone, money must have no >>>>>>>> memory, and so only the current owner is known for a given piece of >>>>>>>> currency, previous owners are purged from the records when a new >>>>>>>> transaction is confirmed. >>>>>>>> >>>>>>>> There are lots more details to all of this if anyone is interested. >>>>>>>> >>>>>>>> Not sure if perhaps you're all more interested in forwarding the >>>>>>>> established ideas, but I wanted to throw this out there since I still do >>>>>>>> not yet see any proposals which would allow me to send that $5 directly to >>>>>>>> my brother!! :) >>>>>>>> >>>>>>>> thanks. >>>>>>>> >>>>>>>> >>>>>>>> Dave Lampton >>>>>>>> * @dave_lampton <https://twitter.com/dave_lampton>* >>>>>>>> >>>>>>>> * DaveLampton <https://www.facebook.com/DaveLampton> +DaveLampton >>>>>>>> <https://www.google.com/+DaveLampton>* >>>>>>>> www.linkedin.com/in/davelampton/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jun 3, 2014 at 4:40 AM, Joseph Potvin <jpotvin@opman.ca> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I don't recall seeing anything specific yet about basic timeliness >>>>>>>>> of >>>>>>>>> web payments. >>>>>>>>> >>>>>>>>> Here's an example. In the course of having some funds reimbursed >>>>>>>>> to me >>>>>>>>> by a business via PayPal, I then transferred the money from my >>>>>>>>> PayPal >>>>>>>>> account to my bank account. Once that transaction was processed via >>>>>>>>> the PayPal site, I recieved the following emaIl message: >>>>>>>>> >>>>>>>>> ---------- Forwarded message ---------- >>>>>>>>> From: service@intl.paypal.com <service@intl.paypal.com> >>>>>>>>> Date: Tue, Jun 3, 2014 at 7:03 AM >>>>>>>>> Subject: We're transferring money to your bank >>>>>>>>> To: Joseph Potvin <jpotvin@opman.ca> >>>>>>>>> >>>>>>>>> We're transferring money from PayPal to your bank >>>>>>>>> Jun 3, 2014 07:03:36 GMT-04:00 >>>>>>>>> Hello Joseph Potvin, >>>>>>>>> You asked us to transfer $XXX.XX CAD from PayPal to your bank >>>>>>>>> account, >>>>>>>>> and we're processing it now. It usually takes 3-5 business days for >>>>>>>>> transfers like this to go through, so you should see the money in >>>>>>>>> your >>>>>>>>> bank account by Jun 10, 2014. >>>>>>>>> ----------------------------------------------- >>>>>>>>> >>>>>>>>> Huh? 3-5 business days? But the ACH system clears at least >>>>>>>>> every day. >>>>>>>>> >>>>>>>>> Does anyone here know in which organization's hands the money sits >>>>>>>>> for >>>>>>>>> 3-5 days? And why? >>>>>>>>> >>>>>>>>> Is this a delay due to some slow anti-launderiing verification >>>>>>>>> processes mandated by government? >>>>>>>>> >>>>>>>>> Alternatively I can imagine there's a cloth bag tied with sisal >>>>>>>>> containing my $XXX.XX CAD being loaded onto a side-bag of a donkey, >>>>>>>>> getting ready to make the trek in this direction. I'm fine with >>>>>>>>> that. >>>>>>>>> Just need to know though. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Joseph Potvin >>>>>>>>> Operations Manager | Gestionnaire des opérations >>>>>>>>> The Opman Company | La compagnie Opman >>>>>>>>> jpotvin@opman.ca >>>>>>>>> Mobile: 819-593-5983 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Joseph Potvin >>>>>>> Operations Manager | Gestionnaire des opérations >>>>>>> The Opman Company | La compagnie Opman >>>>>>> jpotvin@opman.ca >>>>>>> Mobile: 819-593-5983 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> <819-593-5983> >>>> >>> >>> >> >> >> -- >> Joseph Potvin >> Operations Manager | Gestionnaire des opérations >> The Opman Company | La compagnie Opman >> jpotvin@opman.ca >> Mobile: 819-593-5983 >> > > -- Joseph Potvin Operations Manager | Gestionnaire des opérations The Opman Company | La compagnie Opman jpotvin@opman.ca Mobile: 819-593-5983
Received on Wednesday, 4 June 2014 10:58:50 UTC