good riddance to PayPal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 05/06/2016 10:29 AM, Jakob Bohm wrote:
> On 06/05/2016 15:26, Steve Marquess wrote:
>> On 05/06/2016 09:14 AM, Jakob Bohm wrote:
>>> On 06/05/2016 13:45, Salz, Rich wrote:
>>>>> Consider having the non-U.S. person do the account setup too.
>>>>>
>>>>> Banks are as scared of US jurisdiction as crypto engineers.
>>>> Yeah, we've done that.  Even to the point where one of the team was
>>>> going to get on a plane to fly to the Isle of Mann.
>>>>
>>>> It's amazingly painful and difficult and so far not productive.
>>>>
>>>> If folks want to give OpenSSL money, mail a check or cash.
>>> I was thinking of the more simple solution of setting up
>>> the account in the same non-US bank where the team member
>>> does his other business.  Lots of this tends to get easier
>>> when the person is an existing customer and the bank is
>>> nearby.
>>>
>>> Each non-US team member presumably has at least one existing
>>> bank relationship and presumably knowledge and/or easy access
>>> to information on how to set up an independent legal entity
>>> in his/her own country.
>> Personal bank accounts, yes. But, we don't want to entangle OpenSSL
>> funds with any team members personal finances. Those funds need to be
>> held by an independent OpenSSL legal entity (of which there are already
>> several). Also keep in mind that most of my colleagues are hardcore
>> geeks best suited to wrangling OpenSSL code. I try to handle as many
>> paperwork hassles as possible to free them for that more important
>> activity.
> I was trying to say that retail banks can be very helpful
> when an existing personal account holder wants to set up a
> business account with themselves as a signatory (but not
> owner).  Especially if the legal entity (new or existing)
> is also within their jurisdiction.
> 
> Things like checking if the person is who his says he is,
> checking if the initial deposit is from a suspect source
> etc. become much simpler when the bank recognizes the
> person as someone they have worked with for years and the
> initial money source as an account that was the
> correspondent with past checks or other traceable
> transfers to/from that known person (all according to the
> banks own records).

That is definitely true, which is how I was able to get our local U.S.
bank here to allow signature access to our accounts by non-U.S.
colleagues. It's important that our OpenSSL funding not be accessible by
only one person, as that person could be run over by a beer truck.

Unfortunately a U.S. bank is less than ideal for a non-U.S. centric
organization with funding largely originating from, and spent, outside
the U.S.

We have been less successful in finding a non-U.S. bank willing to have
us as a customer, and not for lack of trying. If you know of a
*specific* bank that would help us please name it (offline if need be).
If we haven't already tried them we will.

> Throw in the prospect of earning transaction fees on an
> associated Merchant account, and motivation can grow
> further.

The U.S. payment processors I've talked to don't like the fact that our
web servers are all located outside the U.S. Based on an offline tip
from another user I've spent a good part of this morning on the phone
with a global payments provider; we're at the familiar "uh, we'll have
to run this by underwriting" stage.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux