good riddance to PayPal

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

 



Marquess:

your treasury re-alignment might be simplified a bit if you look to an 
on-line-type bank such as Ally Bank. while they are not on the SWIFT network, 
they use Chase -- like many intermediate-sized banks -- and benefit from having 
the "wholesale" rate between themselves. this enables Ally to give you free 
in-coming SWIFT and free in-coming/out-going domestic US wire transfers. 
out-going SWIFT is only $10. out-going ACH is also free, but they do not provide 
an API for in-coming ACH so that would require a third-party processor to make 
that happen on a web-site or automated/directed basis.

fortunately, such a processor is dwolla which has several API's in different 
codings and offers free in-/out-processing with clearance that usually happens 
no later than the second day after initiation. since ACH has a built-in deferred 
relay of the next business day after preliminary settlement, this speed is about 
as good as it gets. since using a dwolla API also lifts the PCI responsibility 
from openssl, you would receive all your US-based donations at no-cost, quickly, 
and without much regulatory worry. in fact, dwolla allows you to tie in more 
than a single bank account so that you can choose where to "sweep" accumulated 
funds according to momentary needs.

dwolla also has a "white-label" API that totally obscures their role in the 
process. they do charge for this, but the fact that your org is so prominent in 
the net security field would no doubt favorably prompt them to throw this 
service in for free just so they could tout openssl as a client. i am also 
certain they would be more than happy to provide free app customization tailored 
to openssl's specific needs.

if multi-currency is a concern, Citibank offers primary bank account and card 
services in NYC and London permitting a wide range of denominations (USD, GBP, 
EURO, et cetera) from which to base such transactions. also, NYC/London do not 
have to be the same denomination and enjoy free inter-account transfers. from my 
experience, Citi also runs currency translations with much narrower spreads than 
other large banks and third-party gateways. as might be expected for this mega 
bank, their basket of services over-flows and they are lower-cost than other 
major banks when the services are not free!

you have mentioned server-siting and non-US personnel as control agents as 
somewhat problematic. i might suggest a simple and very low-cost means of 
obviating these concerns. if openssl were to incorporate as a type IRS Reg 
501(c)(3) it would satisfy US Treasury Reg's and make life a lot easier. in 
California (one of the lowest-cost states) that would cost you $30 to 
incorporate, $20 to file the SI-100 info form, and $25 to register with the FTB. 
you would also have to register with the CA Attorney General, but that is free. 
thus, for a start-up fee of $75 and a bi-annual SI-100 fee of $20 you would be 
in business and could open any US-based bank account your heart desires and make 
possible using a bank such as Citibank with accounts both in NYC and London to 
meet your international banking needs. since the corporation is a domestic one, 
bank signature cards can be initiated for anyone no matter where they may be 
citizens/domiciled. server siting is no problem for ACH since the natural 
limitation of the sending/receiving accounts being US-based means where the 
servers might be is totally unimportant.

at this time, i am not a client or agent of any of the firms herein mentioned 
and i do not look to receiving any remuneration resulting from any of my 
suggestions.

--
Thank you,

Johann v. Preu?en


On 2016.May.06 08:06, Steve Marquess wrote:
> 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.
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3825 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160511/ef1c4f3a/attachment.bin>


[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