Open Banking with Curve

I am aware of the fact that Curve is going to use the PSD2 data offered by banks in the future. It will definitely let us be better informed about our spending when we can check our balance in the app. But what about Curve sharing its data as well? The Curve Connect platform looks way underdeveloped and kind of forgotten for me.

A possibility to access my own financial data using some sort of API would be awesome. Another alternative could be IFTTT and/or Siri Shortcuts! support. I realise that that may cause some sort of security concerns, but it would greatly improve the overall experience. Just look at the way Curve Receipts work right now. They really come in handy, but imagine if instead of being sent an e-mail every time you make a transaction you could set any other action, such as adding the details to a spreadsheet or saving some portion of the value. On the top of that, the time The Curve Team needs to spend to prepare every new smart function would be vastly saved with this one-size-fits-most solution, as other teams could use some of their workforce to prepare any potential integration.

It took an entirely new regulation for the big banks to start sharing their data. Don’t be like them, beat them! :facepunch:


I think a simple data export option would be great to start with.
I recommended integrating with EMMA, but can’t see that happening

1 Like

It would be great if Curve could allow us API access to let us customize how our card works.

This could be extremely powerful.

We could see that there’s a transaction from a certain merchant then allocate that to a specific card.

We could change merchant display names.

We could automate certain merchants being set to particular categories.

Perhaps you could even allow us to dynamically switch card currency based on incoming transactions? For instance if a payment in a supported currency comes in: my underlying card switches to that, alternatively it would charge me in my card’s base currency (GBP)

The possibilities aren’t endless but they aren’t far off :slight_smile: perhaps you could even allow us to categorize merchants that we know put authorization holds/holding for deposit and set the amount range that their deposits/authorizations are in and then allow us to prevent billing that unless they actually claim the money

Perhaps it’d also be possible to allow us to connect our own platforms to Curve? This way Curve could truly be your entire account in one

It would be great if you guys could consider this. You could even just limit it to metal customers and provide no hardware/software (besides a web socket based API and the documentation preferably as this will be relying on incoming data on a potentially continuous basis)

I personally would have no faults should Curve do this :slight_smile:

Also perhaps you could use this to allow us to change what we use for currency conversion? Personally I would use Transferwise rather than your current partner.

@Curve_Ivo @Curve_Marie :wink: If one of you could talk to your engineering/product about this - I’m sure at the very least they’ll think it could be cool to do.

Certainly would be a first and across all of Europe too definitely a winner for many people - I would personally upgrade to yearly metal and never stop redeeming. Especially as Curve is planning US expansion :slight_smile:

1 Like

Why would you want this to be a websocket api? I don’t think it would be realistic to need real time open socket communication for anything you mentioned there? Doing card selection at payment time would be a really bad thing to do too. It would mean that Curve need to open a socket to your service, or make an http request to your service, to ask what card to use, adding a bunch of extra hops in the processing time.

Having something that would allow retro active switching would be cool though, even if Curve charge your default card, send a request to a webhook you have and have that make the card choice using go back in time.


Well I can’t think of another way to make this work without a WebSocket API as you need to send data across both channels - Curve to me and me to Curve. This needs to happen real-time.

How else would you propose an instant consistent connection

I disagree - it’d be incredibly powerful and Curve could default to their original behavior should my end of the WebSocket be closed or not responding.

Keep the socket open, don’t shut it? It’s not difficult: Discord scaled WebSockets using Elixir to 5m people. Much more customers than Curve have and Discord are still growing significantly and will continue to scale. (the article about scaling WebSockets to such an amount was over 6 months ago minimum, if not a year)

You’re right - there’s a potential for the time to go up but in practice if it’s just me running something for my account it’s unlikely to add anything more than a few ms since the socket would already be opened up.

That’s inefficient.

You’re proposing Curve fires to a webhook and then I send a response back? Normally the idea of webhooks is: I send data to a webhook. the service enacts on what i send it and sends a response back. 401/403/200 etc.

That’s a bunch of unncessary processing when in theory there shouldn’t be more than a couple of ms of added response time when using WS and you could have this actually processed in the realtime with no back and forth. Just one setup of the socket and then continued use of just pushing raw data for either side to interpret. None of that gubbins revolving around HTTP. It;'s simply not meant for what I’m proposing.

The idea of Curve API was already mentioned on this forum a few times.

Please vote and reply in respective threads.


To summarize it, you’re comparing an Apple to a banana. Both are fruits, but they aren’t the same fruit. The kind of API is entirely different.

Open Banking isn’t the kind of API I want, it’s not even similar. I’m asking for granular controls over how Curve works by sending data between external servers and Curve.

Please ask to pry for more information if you don’t understand in the future, rather than commenting and getting my thread wrongly merged as a result, especially when you don’t know the related field to the topic. I’ve messaged Marie to ask her to undo this.


Please read the actual post rather than just the title next time. Both my OG post directly, and linked @Dann’s post about Siri Shortcuts! suggest that I referred to both the data access from Curve and control over the service. While my main point in this thread was the first part, other mentioned resources made it clear that it wasn’t limited in that matter. I appreciate your input, but in my opinion joining these two conversations could mutually enrich them and focus Curve Team’s attention on the matter as one with a long and consistent customer demand. I’ve wanted to avoid watering down the issue, but that seems to be your point.

As your conversations with Marie go, that doesn’t concern me, so I don’t get how is that an important information.