# Real-time authorisations

**URL:** <https://community.monzo.com/t/real-time-authorisations/41356>\
**Category:** Feedback & Ideas\
**Created:** [2 July 2018 18:25 UTC](https://community.monzo.com/t/real-time-authorisations/41356 "2018-07-02T18:25:41Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![anon16572131](https://avatars.discourse-cdn.com/v4/letter/a/db5fbb/32.png) [@anon16572131](https://community.monzo.com/u/anon16572131)\
**Post date:** [2 July 2018 18:25 UTC](https://community.monzo.com/t/real-time-authorisations/41356/1 "2018-07-02T18:25:41Z")

</div>

**Goal**

Prevent frauds rather than dealing with consequences after they happen.

**Solution**

When the card is being used, rather than just sending a notification about the fact, require a user to confirm that in the app.

That would probably have a time limit - when not approved in timely manner the transaction would fail.

**What can be build on top of it**

- After the transaction failed because of timeout, it can be still approved - the next transaction for the same merchant for the same amount wouldn’t require approval again (probably with some time limit - 30m, 1h, 24h?)
- White list - approval never required for merchants chosen by the user (just click on the transaction and add to the white list)
- White list with limits - set a maximum amount for a white listed merchant, if exceeded the approval will be required
- Opt-in/out - possibility to enable/disable this feature, when enabled that would effectively be a safe mode, drastically reducing a chance of fraudulent transactions
- Automatic pattern analysis and recognition - even when disabled, you could still require authorisation from the user for suspicious transactions (based e.g. on location, amount, previous usage etc.)

**Similar ideas**

> [@Transaction Limits and Pre-Authorisation](https://community.monzo.com/t/transaction-limits-and-pre-authorisation/38915):
>
> Hi there, great product! I’ve been having problems with fraud lately on my credit card. I had a couple of ideas about trying to make this harder for criminals to do, here’s one. I typically have a selection of merchants that I use frequently (Amazon, Ocado, etc) and a bunch of subscriptions to services and charities. Most of those services have a regular pattern. Subscriptions are the exact same amount for years on end, things like Ocado are typically in a range that goes from a number to doub…

> [@Joint Accounts 1 & Real-time Authorisations](https://community.monzo.com/t/joint-accounts-1-real-time-authorisations/304):
>
> Hi Guys, I absolutely love the near real-time’ness of the transaction notifications and it got me thinking that leveraging it might be useful in the use case of linked cards. e.g. Family groups where one or more parents have issued cards to their children and the one or both parents receive a notification not just to view the transaction, but to catch it in-flight and accept or reject it. You could set up rules around the notifications/authorisations like granting autonomy for individual tra…

---

<div class="post-metadata">

**Author:** ![anon77363772](https://avatars.discourse-cdn.com/v4/letter/a/3da27b/32.png) [@anon77363772](https://community.monzo.com/u/anon77363772)\
**Post date:** [2 July 2018 21:38 UTC](https://community.monzo.com/t/real-time-authorisations/41356/2 "2018-07-02T21:38:06Z")

</div>

The problem is that when you / someone else presents your card to a card terminal (contactless or chip and pin), Monzo only has a few hundred milliseconds to decide whether to accept or decline a transaction. So this would only work for online transactions, which Monzo is planning on implementing via 3D Secure (which is on the near-term roadmap).

---

<div class="post-metadata">

**Author:** ![anon16572131](https://avatars.discourse-cdn.com/v4/letter/a/db5fbb/32.png) [@anon16572131](https://community.monzo.com/u/anon16572131)\
**Post date:** [2 July 2018 21:57 UTC](https://community.monzo.com/t/real-time-authorisations/41356/4 "2018-07-02T21:57:04Z")

</div>

I admit I don’t know technical details behind payments, but are you sure it’s only a few hundred milliseconds? I have sometimes seen “authorising” on the terminals for 5-10 seconds, which would be enough to approve it in the app.

---

<div class="post-metadata">

**Author:** ![anon77363772](https://avatars.discourse-cdn.com/v4/letter/a/3da27b/32.png) [@anon77363772](https://community.monzo.com/u/anon77363772)\
**Post date:** [2 July 2018 22:00 UTC](https://community.monzo.com/t/real-time-authorisations/41356/5 "2018-07-02T22:00:08Z")

</div>

The card terminals need to connect to their acquirer, who then have to connect to the buyer’s card network (Visa/MasterCard/Amex), who then forward the authorisation request to the buyer’s bank (in our case, Monzo).

I remember seeing this “a few hundred milliseconds” figure being posted somewhere by a member of staff somewhere here. I’m sure @anon41219820 can give more info.

---

<div class="post-metadata">

**Author:** ![Feathers](https://dub1.discourse-cdn.com/monzo/user_avatar/community.monzo.com/feathers/32/45868_2.png) [@Feathers](https://community.monzo.com/u/Feathers)\
**Post date:** [2 July 2018 22:16 UTC](https://community.monzo.com/t/real-time-authorisations/41356/6 "2018-07-02T22:16:15Z")

</div>

In my head it’s 200ms, far too short for any sort of user interaction but take that with a pinch of salt unless I can find a source somewhere.

---

<div class="post-metadata">

**Author:** ![anon77363772](https://avatars.discourse-cdn.com/v4/letter/a/3da27b/32.png) [@anon77363772](https://community.monzo.com/u/anon77363772)\
**Post date:** [2 July 2018 22:17 UTC](https://community.monzo.com/t/real-time-authorisations/41356/7 "2018-07-02T22:17:52Z")

</div>

That’s the figure I remembered, but wasn’t sure.  
Can’t remember on which thread I read it though.  
There are several threads where this figure is mentioned.

---

<div class="post-metadata">

**Author:** ![anon16572131](https://avatars.discourse-cdn.com/v4/letter/a/db5fbb/32.png) [@anon16572131](https://community.monzo.com/u/anon16572131)\
**Post date:** [2 July 2018 22:33 UTC](https://community.monzo.com/t/real-time-authorisations/41356/8 "2018-07-02T22:33:53Z")

</div>

Hmmm… It could still be done by approving it upfront - e.g. if you are about to buy your lunch, you could specify in the app that the next transaction for up to £10 in the next 15 minutes is ok.

Or just letting the first transaction fail, so that in the app I could just select it and click “approve it next time”.

That might be less convenient, but with a white list, this is the extra security that I would definitely sign up for.

---

<div class="post-metadata">

**Author:** ![ianlyon](https://dub1.discourse-cdn.com/monzo/user_avatar/community.monzo.com/ianlyon/32/54211_2.png) [@ianlyon](https://community.monzo.com/u/ianlyon)\
**Post date:** [2 July 2018 22:41 UTC](https://community.monzo.com/t/real-time-authorisations/41356/9 "2018-07-02T22:41:29Z")

</div>

> [@Feathers](#):
>
> In my head it’s 200ms, far too short for any sort of user interaction but take that with a pinch of salt unless I can find a source somewhere.

That’s correct - it’s 200ms 🙂

---

<div class="post-metadata">

**Author:** ![anon16572131](https://avatars.discourse-cdn.com/v4/letter/a/db5fbb/32.png) [@anon16572131](https://community.monzo.com/u/anon16572131)\
**Post date:** [2 July 2018 22:45 UTC](https://community.monzo.com/t/real-time-authorisations/41356/10 "2018-07-02T22:45:35Z")

</div>

@ianlyon Developer’s curiosity - where does this limitation come from? I assume that something, somewhere has 200ms timeout and will fail the transaction if there is no response in that time?

---

<div class="post-metadata">

**Author:** ![Anarchist](https://dub1.discourse-cdn.com/monzo/user_avatar/community.monzo.com/anarchist/32/27895_2.png) [@Anarchist](https://community.monzo.com/u/Anarchist)\
**Post date:** [2 July 2018 23:21 UTC](https://community.monzo.com/t/real-time-authorisations/41356/11 "2018-07-02T23:21:16Z")

</div>

I think that freezing the card and defrosting it prior to each transaction would achieve a sufficiently similar result.

---

<div class="post-metadata">

**Author:** ![alexs](https://dub1.discourse-cdn.com/monzo/user_avatar/community.monzo.com/alexs/32/2443_2.png) [@alexs](https://community.monzo.com/u/alexs)\
**Post date:** [3 July 2018 06:40 UTC](https://community.monzo.com/t/real-time-authorisations/41356/12 "2018-07-03T06:40:51Z")

</div>

Yes, the problem there of course is what if you don’t have a data connection.

---

<div class="post-metadata">

**Author:** ![anon16572131](https://avatars.discourse-cdn.com/v4/letter/a/db5fbb/32.png) [@anon16572131](https://community.monzo.com/u/anon16572131)\
**Post date:** [3 July 2018 07:43 UTC](https://community.monzo.com/t/real-time-authorisations/41356/13 "2018-07-03T07:43:30Z")

</div>

> [@Anarchist](#):
>
> I think that freezing the card and defrosting it prior to each transaction would achieve a sufficiently similar result.

Not exactly, there are a few main differences:

1. Approval before the transaction and nothing afterwards VS defrosting the card before and freezing it after
2. Other (fraudulent) transactions could go through in this short window of time - selecting rejected transaction to allow it next time would prevent that
3. This approach will not work with automatic payments that could happen at any day and time (e.g. TfL’s Oyster auto top-up)
4. White list could practically eliminate need for approvals depending on the use case - I can only speak for myself, but I have a bunch of online services which I use regularly and a couple of places where I go for lunch. That’s about 20-30 items on the white list that would completely eliminate the need for approving transactions for me, with the exception of when I am on holidays.

---

<div class="post-metadata">

**Author:** ![Rat\_au\_van](https://dub1.discourse-cdn.com/monzo/user_avatar/community.monzo.com/rat_au_van/32/49103_2.png) [@Rat\_au\_van](https://community.monzo.com/u/Rat_au_van)\
**Post date:** [3 July 2018 08:01 UTC](https://community.monzo.com/t/real-time-authorisations/41356/14 "2018-07-03T08:01:28Z")

</div>

I have never had a fraudulent transaction on any of my cards. It’s such a tiny percentage that I’m not sure there’s a need. If it does happen Monzo refund within an hour.  
What happens if you have no data/signal/battery and want to buy something you happen to see on sale?

---

<div class="post-metadata">

**Author:** ![anon16572131](https://avatars.discourse-cdn.com/v4/letter/a/db5fbb/32.png) [@anon16572131](https://community.monzo.com/u/anon16572131)\
**Post date:** [3 July 2018 08:08 UTC](https://community.monzo.com/t/real-time-authorisations/41356/15 "2018-07-03T08:08:08Z")

</div>

> [@Rat\_au\_van](#):
>
> I have never had a fraudulent transaction on any of my cards. It’s such a tiny percentage that I’m not sure there’s a need.

Until another data breach of a service where you have your card remembered (like Ticketmaster recently).

> [@Rat\_au\_van](#):
>
> If it does happen Monzo refund within an hour.

Preventing it would save time and effort for both sides and potentially a lot of money for Monzo in case of fraudulent transactions that cannot be reverted (e.g. ATM withdrawal)

> [@Rat\_au\_van](#):
>
> What happens if you have no data/signal/battery and want to buy something you happen to see on sale?

That’s a risk you might or might not want to take. Again it depends on the use case - I rarely fall for such sales and rarely have no data/signal/battery.

---

<div class="post-metadata">

**Author:** ![alexs](https://dub1.discourse-cdn.com/monzo/user_avatar/community.monzo.com/alexs/32/2443_2.png) [@alexs](https://community.monzo.com/u/alexs)\
**Post date:** [3 July 2018 09:21 UTC](https://community.monzo.com/t/real-time-authorisations/41356/16 "2018-07-03T09:21:56Z")

</div>

> [@anon16572131](#):
>
> > What happens if you have no data/signal/battery and want to buy something you happen to see on sale?
> 
> That’s a risk you might or might not want to take.

No it’s not. Even if you only have that problem 1% of the time (which is optimistic) you have a real problem when you do.

I appreciate the fact that you have good intentions here but it seems like you haven’t really thought this through. As you’ve mentioned, issuers have an incentive to reduce fraud so if this was a good idea, it would have been done already, it’s not hard to implement.

---

<div class="post-metadata">

**Author:** ![alexs](https://dub1.discourse-cdn.com/monzo/user_avatar/community.monzo.com/alexs/32/2443_2.png) [@alexs](https://community.monzo.com/u/alexs)\
**Post date:** [3 July 2018 09:48 UTC](https://community.monzo.com/t/real-time-authorisations/41356/17 "2018-07-03T09:48:57Z")

</div>

Split this topic on 3 July 2018 09:48 UTC

6 posts were split to a new topic: [User confirmation when fraudulent transactions have been flagged](https://community.monzo.com/t/user-confirmation-when-fraudulent-transactions-have-been-flagged/41399)

---

<div class="post-metadata">

**Author:** ![cookywook](https://dub1.discourse-cdn.com/monzo/user_avatar/community.monzo.com/cookywook/32/24136_2.png) [@cookywook](https://community.monzo.com/u/cookywook)\
**Post date:** [3 July 2018 11:34 UTC](https://community.monzo.com/t/real-time-authorisations/41356/18 "2018-07-03T11:34:36Z")

</div>

Split this topic on 3 July 2018 11:34 UTC

8 posts were split to a new topic: [Removed Posts - 3/7/18](https://community.monzo.com/t/removed-posts-3-7-18/41420)

---

<div class="post-metadata">

**Author:** ![anon16572131](https://avatars.discourse-cdn.com/v4/letter/a/db5fbb/32.png) [@anon16572131](https://community.monzo.com/u/anon16572131)\
**Post date:** [3 July 2018 10:00 UTC](https://community.monzo.com/t/real-time-authorisations/41356/19 "2018-07-03T10:00:41Z")

</div>

> [@alexs](#):
>
> > > What happens if you have no data/signal/battery and want to buy something you happen to see on sale?
> > 
> > That’s a risk you might or might not want to take.
> 
> No it’s not. Even if you only have that problem 1% of the time (which is optimistic) you have a real problem when you do.

And what about that 1% of times when the merchant has problems with their terminal or connection is down and you cannot pay with card at all? Or what about stalls on the food market which often accept cash only? Should we all give up our cards and go back to cash only, because in 1% of cases you cannot use your card anyway?

> [@alexs](#):
>
> I appreciate the fact that you have good intentions here but it seems like you haven’t really thought this through.

Then help improve this idea.

---

<div class="post-metadata">

**Author:** ![jzw95](https://dub1.discourse-cdn.com/monzo/user_avatar/community.monzo.com/jzw95/32/5896_2.png) [@jzw95](https://community.monzo.com/u/jzw95)\
**Post date:** [3 July 2018 10:36 UTC](https://community.monzo.com/t/real-time-authorisations/41356/27 "2018-07-03T10:36:42Z")

</div>

> [@anon16572131](#):
>
> where does this limitation come from?

This is an old blog post, but shows the different stages of a transaction:

> **[3 Second Sandwich](https://monzo.com/blog/2015/12/02/3-second-sandwich/)**
>
> Mondo recently rolled out our Alpha program to 500 lucky testers. If you weren’t...

My memory from previous discussions on this forum is that the 200ms requirement comes from the card network (Mastercard in this case). I assume this is so that transactions don’t take too long end-to-end.

Often the long time you see the card machine ‘authorising’ for is because that initial connection from the shop to the acquirer takes a while. Some shops still use dial-up modems for this. 😮

---

<div class="post-metadata">

**Author:** ![alexs](https://dub1.discourse-cdn.com/monzo/user_avatar/community.monzo.com/alexs/32/2443_2.png) [@alexs](https://community.monzo.com/u/alexs)\
**Post date:** [3 July 2018 10:38 UTC](https://community.monzo.com/t/real-time-authorisations/41356/28 "2018-07-03T10:38:08Z")

</div>

Yes as far as I know, it’s only Monzo that has to respond within the 200ms window, presumably because other steps of the process can take such a long time 😬

[Next page](https://community.monzo.com/t/real-time-authorisations/41356.md?page=2)
