Jump to content
Sign in to follow this  
suggestionengine

No Reversible Transactions for Banks?

Recommended Posts

I have a question about reversible transactions for banks.  Is it true to say that Banks need reversible transactions in case they get hacked?  If their systems are connected up to XRP bought using their xrapid setup, XRP could be bought and sent to an address they do not already trust (the hacker, rather than another bank), how can this be mitigated against?

Obviously being a blockchain the whole point is this is an independent currency where there are no reversible transactions, so does this create risk for a bank?

Thanks looking forward to replies.

Edited by suggestionengine

Share this post


Link to post
Share on other sites

I'm not an expert but as I understand it...

It's true that an important part of banking is that they may wish to reverse a transaction.  You can't revert a XRapid transaction.  Blockchain is immutable.

But you can reverse the transaction by sending the equivalent amount back the other way.  It's not totally trivial because of fees but Xrapid knows fees in advance so it can be done.

But also you should ask why are we trying to reverse?  One big reason is because of the flakiness of the current system.  That's gone with XRapid so a big percentage of the reason to even try reverting is gone too.

Your question about incorrect address just can't happen.....  The pathfinding is part of the Ripplenet advantage and will only go where trust is established.

So overall....  It can be done but it won't need to be done as often.

 

Share this post


Link to post
Share on other sites

thanks for the reply.  

I understand that incorrectly sent money could be sent back in another (very cheap) transaction, providing it had been accidentally sent to someone trustworthy enough to send it back (like another bank) - but the scenario I am wondering about is if the bank was hacked.  The hacker might be able buy some XRP from the banks interfaces and then withdraw it and there would be nothing the bank could do about it.

Share this post


Link to post
Share on other sites
9 minutes ago, suggestionengine said:

thanks for the reply.  

I understand that incorrectly sent money could be sent back in another (very cheap) transaction, providing it had been accidentally sent to someone trustworthy enough to send it back (like another bank) - but the scenario I am wondering about is if the bank was hacked.  The hacker might be able buy some XRP from the banks interfaces and then withdraw it and there would be nothing the bank could do about it.

Um er,. I don't think that is how it works...  The bank doesn't buy XRP....   a scripted set of automated transactions do it within XRapid.  

If in some way the bank is hacked enough to access down into core software then the XRP risk is the least of the banks worries.... 

Share this post


Link to post
Share on other sites
1 minute ago, suggestionengine said:

ok, thanks.  It's just that a bank hacker can only withdraw to another bank though so they may well get caught (presumably?), whereas they could get away with the XRP.

The "to another bank" option has allowed billions of dollars worth of fraud to dissapear completely over the years....   XRP doesn't significantly add anything to banks risk that wasn't already there.

Share this post


Link to post
Share on other sites

Although the blockchain is irreversible, you can send it back to where it came from but that would take both parties agreeing. If you want to be as safe as possible, I would recommend XCH4NGE. They are introducing a new method of payment processing through their corporate account and they have 24/7 support so that's probably your best bet. 

Edited by coinologist

Share this post


Link to post
Share on other sites

I think this is certainly something that should be considered. At the very least, have something similar the the escrow function that is already built in to the protocol. For example, an artificial delay where a transaction can be cancelled in a certain window of time. This could be 5 minutes or 5 days.

Manifest errors are a common problem in finance (hot dog fingers causing typos) so I think this is a feature that would be welcomed as long as it can't be used to trick a recipient into thinking the payment settled (it would need a pending status with countdown)

Share this post


Link to post
Share on other sites
8 hours ago, MaxWeber said:

I think this is certainly something that should be considered. At the very least, have something similar the the escrow function that is already built in to the protocol. For example, an artificial delay where a transaction can be cancelled in a certain window of time. This could be 5 minutes or 5 days.

Manifest errors are a common problem in finance (hot dog fingers causing typos) so I think this is a feature that would be welcomed as long as it can't be used to trick a recipient into thinking the payment settled (it would need a pending status with countdown)

To me that seems unneeded and overly complicated.  Human errors in the transactions can be corrected in the normal ways...   contact and explanations between parties.  If agreeement is reached then remedying transactions can be performed.

It is generally a bad idea to overly complicate things especially when there is no clear and pressing need. That’s just my opinion...  

Share this post


Link to post
Share on other sites
19 hours ago, Tinyaccount said:

To me that seems unneeded and overly complicated.  Human errors in the transactions can be corrected in the normal ways...   contact and explanations between parties.  If agreeement is reached then remedying transactions can be performed.

It is generally a bad idea to overly complicate things especially when there is no clear and pressing need. That’s just my opinion...  

Come to think of it, I think this is precisely what the escrow feature is capable of. https://ripple.com/dev-blog/explanation-ripples-xrp-escrow/

Banks would just need to incorporate it into their practices and it would have the desired effect.

Without getting into a philosophical debate, I can clearly see why this is a needed feature even beyond error reversals.

Share this post


Link to post
Share on other sites
4 hours ago, MaxWeber said:

Come to think of it, I think this is precisely what the escrow feature is capable of.

As I understand it ( and I could be wrong) Xrapid is apparently atomic...  the transaction all works or it all doesn’t.  

I believe there are escrows as part of that, with the release conditions being success at all sub sections.  I don’t know how it works and I don’t think it’s on the XRPLedger.  I think it’s done with ILP somehow.

Having said that...  I don’t believe that there is a ‘let’s wait a bit and see if we all still want to proceed’ step.   As I say...  I think that is unneeded and making a simple thing needlessly more complicated.  But I don’t know the fine details,  and it’s entirely possible that your idea is already implemented.  I doubt it but am happy to be schooled if anyone knows for sure.

Share this post


Link to post
Share on other sites
On 1/7/2019 at 4:14 AM, Tinyaccount said:

As I understand it ( and I could be wrong) Xrapid is apparently atomic...  the transaction all works or it all doesn’t.  

I believe there are escrows as part of that, with the release conditions being success at all sub sections.  I don’t know how it works and I don’t think it’s on the XRPLedger.  I think it’s done with ILP somehow.

Having said that...  I don’t believe that there is a ‘let’s wait a bit and see if we all still want to proceed’ step.   As I say...  I think that is unneeded and making a simple thing needlessly more complicated.  But I don’t know the fine details,  and it’s entirely possible that your idea is already implemented.  I doubt it but am happy to be schooled if anyone knows for sure.

No worries, I don't know much about international banking at the enterprise level nor do I even fully understand the ripple protocol!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...