P2P banks, 1 line of code • Hacker News Board

Re: P2P banks, 1 line of code

#21

Post by Firehed » Thu, Jan 17, 2013, 5:32 AM UTC

lisper wrote: post #14

gfunk911 wrote: post #8

Not sure why all the comments here are harping on the "one line" thing. The point is that you can transfer money with one command and no pre-existing state. That's pretty great.

And no security. That's not so great. EDIT: What I mean by this is that if you give me your account number so that I can deposit into it, then I can also withdraw out of it (not through the Dwolla API, but trivially by other means -- see http://perimetergrid.com/wp/2008/01/01/checks-the-most-dange... )

It's a problem with ACH in general. However, debits from consumer accounts (or, more accurately, those initiated with a "PPD" code) can be refuted for something like two years.

By submitting a file straight to the networks, I could also debit a nonexistent account for $20m and have it show up in my account the next morning. Wouldn't hang around for long though.

Re: P2P banks, 1 line of code

#22

Post by lisper » Thu, Jan 17, 2013, 6:18 AM UTC

makmanalp wrote: post #17

lisper wrote: post #14

Earlier quoted context omitted.

And no security. That's not so great. EDIT: What I mean by this is that if you give me your account number so that I can deposit into it, then I can also withdraw out of it (not through the Dwolla API, but trivially by other means -- see http://perimetergrid.com/wp/2008/01/01/checks-the-most-dange... )

This is an inherent flaw in the system though, right? Not anything new.

Not quite. This makes ACH more accessible than it was before, which makes it that much easier to commit ACH fraud. Also, it is possible to layer a secure layer on top of ACH, but Dwolla didn't do that. They either chose not to, or they don't know how. They just exposed the ACH functionality directly.

Re: P2P banks, 1 line of code

#23

Post by lisper » Thu, Jan 17, 2013, 6:20 AM UTC

Firehed wrote: post #21

lisper wrote: post #14

Earlier quoted context omitted.

And no security. That's not so great. EDIT: What I mean by this is that if you give me your account number so that I can deposit into it, then I can also withdraw out of it (not through the Dwolla API, but trivially by other means -- see http://perimetergrid.com/wp/2008/01/01/checks-the-most-dange... )

It's a problem with ACH in general. However, debits from consumer accounts (or, more accurately, those initiated with a "PPD" code) can be refuted for something like two years. By submitting a file straight to the networks, I could also debit a nonexistent account for $20m and have it show up in my account the next morning. Wouldn't hang around for long though.

You can always refute it. Whether you'll get your money back or not is an entirely different matter. The consumer protections on ACH are much weaker than credit cards, so it's pretty much up to the discretion of your bank.

Re: P2P banks, 1 line of code

#24

Post by Hansi » Thu, Jan 17, 2013, 6:34 AM UTC

How is this different from saying that communication via Switft messages is really only one line of code at the end that's important?

Re: P2P banks, 1 line of code

#25

Post by zende » Thu, Jan 17, 2013, 6:56 AM UTC

lisper wrote: post #23

Firehed wrote: post #21

Earlier quoted context omitted.

It's a problem with ACH in general. However, debits from consumer accounts (or, more accurately, those initiated with a "PPD" code) can be refuted for something like two years. By submitting a file straight to the networks, I could also debit a nonexistent account for $20m and have it show up in my account the next morning. Wouldn't hang around for long though.

You can always refute it. Whether you'll get your money back or not is an entirely different matter. The consumer protections on ACH are much weaker than credit cards, so it's pretty much up to the discretion of your bank.

It's not that their that much weaker. You have 60 days as an individual to dispute a debit, but it's seriously painful. You will likely have to go into a branch and fill out a physical document. In comparison, Amex has a link that says "dispute" next to each transaction.

Re: P2P banks, 1 line of code

#26

Post by bdonlan » Thu, Jan 17, 2013, 7:31 AM UTC

gfunk911 wrote: post #8

Not sure why all the comments here are harping on the "one line" thing. The point is that you can transfer money with one command and no pre-existing state. That's pretty great.

Great. If you get a timeout, though, what do you do? You will either end up with the possibility of double transactions or no transactions, depending on how you try to recover...

Re: P2P banks, 1 line of code

#27

Post by utunga » Thu, Jan 17, 2013, 7:53 AM UTC

Looking for where someone mentions http://www.opentransact.org but can't find it so I'll mention it.

Re: P2P banks, 1 line of code

#28

Post by DerCed » Thu, Jan 17, 2013, 9:05 AM UTC

"No, at this time Dwolla is only available for use within the United States." That is unfortunate, would have liked to try it out.

Re: P2P banks, 1 line of code

#29

Post by paulnechifor » Thu, Jan 17, 2013, 11:14 AM UTC

shousper wrote: post #16

Is anyone else annoyed at the mix of parameter naming conventions, or is it just me? (e.g. client_id, emailAddress, client_secret, firstName).

If by mixing conventions you mean careless foul practice of trying to please everyone by partially satisfying all of their preferences which only ends up annoying them all, then I am certainly against it. But, if by mixing conventions you mean the joyous unsegregated joining of every person's vision into a creation that is greater than the sum of its parts, then I am certainly for it. This is my stand. I will not retreat from it. I will not compromise.

Re: P2P banks, 1 line of code

#30

Post by deweller » Thu, Jan 17, 2013, 1:26 PM UTC

I'm waiting for someone to create a service on top of this. Think Stripe for ACH transfers.

I badly want to use this but the required BSA/AML and CIP compliance are too much for my startup. I would gladly pay someone to handle this compliance and just let me call an API.