Fintech R&R ☕️ x Under the Hood 🛠 - The Merchant Payment Process, Revoloopholes and the Mandela Effect
A Card Payments deep dive, why Revolut suffers from The Mandela Effect, education & resources for fintech builders, and the Product + Technical expertise debate
Hey Fintechers and Fintech newbies 👋🏽
News came out recently about a $20M heist on Revolut’s US operations early last year.
Ok, ‘heist ‘is stretching it a little.
It was more akin to the Office Space ‘heist’, where plucky office workers installed a small piece of code in the companies’ software that rounded down interest payments instead of rounding them up. The software then swept the remainder of every interest transaction, around 0.0025 of a penny, into a separate account which, over 1000s of transactions, would mean they’d have a small fortune and could quit the job they all hate. Little shoutout to all of you Office Space fans.
While details on the Revolut robbery are still coming out in dribs and drabs, one clear thing is that similar to the Office Space transaction theft, the robbers exposed a loophole in the system.
Apparently, the loophole arose when certain transactions were declined and rather than have these transactions marked and processed as ‘declines’ with a failure reason as part of the transaction authorisation process, they were erroneously processed as refunds meaning that Revolut money was incorrectly deposited into the robbers accounts. Robbers then drained the accounts into physical cash via ATMs until the discrepancy was noticed and the loophole closed.
Now, there are a few areas to explore here, including the benefits of using an external vendor for payments processing and authorisation rules (Revolut built its own platform), work needed to expand to different markets (this is a loophole that was explicitly exploited in the US), and the value of a robust and dependable reconciliation and reporting system (criminals took over $20 million before the loophole was spotted and closed).
Rather than a deep dive into the above areas, I’m taking a look at education within fintech and the question of resources for the people building the future of financial services. Because in-depth resources about the end-to-end process could have mitigated the effects of this loophole from being exposed in the first instance and saved the company 20 million dollars.
But a quick heads up. This edition is a little cheeky as the core content is a repost of something I put together a few years ago (the start of a series called Under the Hood). However, that doesn’t make it any less relevant or essential.
So, in addition to interesting news, puns + movie references, this edition includes the following:
The Merchant Payment Process: Step-by-step
Reasons for creating this explainer
Educating the educators
Great fintech learning resources
How a better understanding might have mitigated the Revoloophole
The Mandela Effect and Revolut’s perceived reputation
The Merchant Card Payment Process: Step-by-step 💳
The following is the step-by-step guide I put together a few years ago with the heading “Under the Hood: The Merchant Payment Process 🛠” designed to give clarity to the end-to-end process of the merchant payment process using a card.
If you’ve already read the write-up, feel free to skip to the next section.
The overarching reason I created it is that understanding the end-to-end process is crucial to building customer-centric products, creating robust and thorough customer support models and finding the right providers to help build, grow and scale the product.
Having clarity over the whole process also highlights areas of improvement and differentiation vs other products on the market, and generally, more knowledge and understanding helps build better products.
I’ll get into a bit more of the origins, but if you don’t know what happens in the background when you go to a physical or online store and purchase goods, then here’s where to start.
Step 1 - Payment Initiation
This is the logical starting point of the merchant payments process. To start the process, there needs to be an exchange of goods or services for payment. In this article, I’ll be focusing on the predominant in-store payment method, which is via a card.
Back in the olden days, there was one way to make a card payment, and that was via a Card Imprinter or ‘Click and Clack machine’ (see below). Remember those!!!
Nowadays, there are multiple methods aside from the more traditional magstripe swipe or ‘dip’ plus signature, which is still quite prominent in the US. Most notably, Chip & Pin, contactless and online card entry. These more modern methods are what I’ll focus on in detail, but the basic payment principle remains the same:
1. Prove that you are the cardholder.
2. Then prove that you have the funds to carry out the transaction.
The next step outlines the first part of the above: Prove that you are the cardholder
Key Players: Merchants and companies with payment facilities
Step 2 - Payment method verification and routing via Merchant Acquirer
At this point in the process, the device or portal checks the details of the card and ensures that the payment method is valid and belongs to the customer. This is the initial verification that occurs BEFORE any payment request is routed to the customer's bank for authorisation and to check for available funds.
NOTE: The only exception to this is contactless payments, where risk is limited to a maximum payment amount which often differs by country and currently up to £100 in the UK. Possession of the card is all the verification required to initiate the process, and risk is limited to £100 per transaction with Chip and PIN required periodically for security purposes, e.g. when a flurry of contactless transactions occurs.
Physical Payment Verification (Chip and Pin) 💳
Valid card with the correct PIN ✅
Customer inserts card is prompted to enter their PIN (Terminal Messaging: 'Enter PIN')
The device verifies that the PIN entered matches the PIN on the card (many card issuers perform the PIN check directly with the chip on the card which is why if you get your PIN wrong you get instant feedback)
The card is valid, active and the current date is before the expiry date
Payment request gets sent to the card network to continue the process and the terminal waits for a response back (Terminal Messaging: 'Processing'/'Authorising'/'Please Wait')
NOTE: The term Card Network and Card Scheme are sometimes used interchangeably but for the purposes of this I'll use network
Other scenarios ❌
The PIN is entered incorrectly 3 times, payment is rejected then the card is usually blocked (Terminal Messaging: 'PIN Failed')
Expiry Date has passed and payment is rejected after PIN check is performed
The card hasn't been activated and payment doesn't get initiated
Online Payment 💻
Customer hits Checkout and selects Card as their payment method
Customer is prompted to enter their:
Name (if not already entered)
Full Card number (length varies depending on the network i.e. Visa, American Express)
Expiry Month and Year
Card Verification Code (CVC)/Card Verification Value (CVV)
Billing Postcode/Address (linked to the account)
3. The online payment portal will instantly check the validity of the card number using the Luhn algorithm and can also verify & display the network the card has been issued under. The first digit of the card denotes the network and the following are the key networks:
3 - American Express/DinersClub/JCB
4 - Visa
5 - MasterCard/Maestro
6 - Discover/Maestro UK
If you have more than one debit or credit card, go check out the differences now
4. As well as the validation of the card number, the Expiry and CVV/CVC will also have basic length and format validation (CVV/CVC being 3 or 4 digits and the expiry of the card being in the future)
5. Once the card details have had basic validation performed and a valid postcode/address has been provided, the portal will attempt to request authorisation and process the payment.
6. More and more merchants are using 3D Secure, which is available with Visa and Mastercard, as an additional layer of security and to shift any liability in failed or fraudulent transactions from the merchant to the customer’s bank.
Merchants that show the ‘Verified by Visa’ or ‘Mastercard Securecode’ logos will have a final verification screen. This screen will summarise the transaction details and, depending on the implementation, either ask for a passcode that was set by the customer or, more likely, send a one-time passcode to the customer’s bank-registered phone number. The customer then enters that code to verify themselves and proceed with the payment.
7. Once all the details have been verified on-screen and 3DS has completed, the payment request is sent to the corresponding card and routed to the customer's bank to continue the authorisation process
Key Players: SumUp, Square, WorldPay (from FIS), Stripe, Zettle
Step 3 - Authorisation Routing via Network
Once the merchant acquirer has provided initial validation checks, the authorisation request is handed over to the network specified in the card. As mentioned earlier, each network is identified on each card and has connectivity with the different merchant acquiring services so in-store or online portals know where to route requests to once details have been validated and submitted.
The network receives the authorisation request containing the customer's card information as well the details about the payment itself (Merchant name, Payment Amount, Currency) which will be used by the customer's bank to give the decision as to whether to authorise the payment or not.
After the request is received from the merchant acquiring service, the network will route the request to the customer's bank for authorisation and use the first 6 digits of the card (the Bank Identification Number, AKA BIN) to ensure they route the request to the correct issuing bank.
Key Players: Visa, MasterCard, American Express, Discover, JCB, DinersClub
Step 4 - Authorisation Routing and Stand-in via Payment Processor
At the stage between the network and the issuing bank, there will often sit a payment processor. This is becoming more and more popular, especially with challenger banks who want to get to market and prove a proposition but don’t have the time to go through the process of building connections and pathways with the network or any of the various payment methods saving time and effort. A payment processor can also make the experience more robust for the customer by providing initial fraud checks on merchants and providing authorisation on behalf of the bank in case the bank’s systems are inaccessible (this is called ‘stand-in’).
When a payment processor is part of the customer’s bank flow, the network will be configured to send authorisation messages here first, and the PP will perform some initial checks, and then forward the message to the Core Banking system of the customer’s bank.
As long as there are no red flags on the merchant at this stage (some accounts will be configured so the PP would reject payments from gambling institutes, for example), then the PP will forward the authorisation to the customer’s bank for a decision on the request.
Key Players: Marqeta, Thredd (formally GPS) Galileo, Visa DPS, Ayden
Step 5 - Authorisation Decision within Core Banking
This is the pivot point of the process (that was a mouthful). It’s where authorisation for the payment is given or denied and then flows back to the merchant, where it’ll pop up on the merchant terminal where we all dread the message of ‘DECLINED!’. The core banking platform is what banks use to hold the source of truth for accounts and balances. Therefore, it’s also the place that will process the authorisation and, if successful, put a block on funds.
There are several due diligence steps that the core banking platform will go through before providing authorisation for the payment request:
Account Status - While most accounts will be 'active' there are occasions where the account status may be 'temporarily locked', 'under review', or have 'suspicion of fraud'. Under some of these states, the account will be blocked from making any new transactions so this is usually one of the first checks
Available Balance - Most people will be aware of checking if the customer has enough available funds in their account. It worth noting that it’s the ‘available’ balance also takes into account any other payment holds that have been put on the account. For example, suppose a customer has £300 in their account and uses their card to reserve a room in a hotel. In that case, the hotel will put a hold of around £200 on the customer’s account for the duration of the stay (as a small deposit in case the customer goes all Rock’n’Roll in their room). Often this money doesn’t leave the account, but it means the customer only has £100 left available to spend until the hold is removed
Risky Merchant - Individual banks maintain lists of blocked merchants and merchants that they may distrust or suspect of fraudulent activity. Core banking platforms will cross-check the merchant against these lists before making a decision on the payment
Suspicious Amount - Banks continuously monitor transactions so they can detect anomalies in spending habits, identify odd habits, and prevent fraud. If the customer’s spending is outside normal behaviour, then the transaction might be declined straight away, or the customer might require additional verification. This is where your bank might call you directly to confirm you attempted the payment and then allow the authorisation to go through. And newer digital banks may ask you to verify in the app that it is in fact, you making the transaction
Once the checks come back clear, the bank will provide authorisation via a code that the merchant terminal will receive. Often these codes are displayed on the terminal itself as well as printed on physical receipts. They are also kept by the merchant as a record of authorisations given for previous transactions.
NOTE: In the majority of challenger propositions, this is the point at where you'll get a notification on your phone that the transaction has been successful/unsuccessful and sometimes BEFORE the authorisation response even gets to the merchants terminal.
Key Players: Mambu, Thought Machine, Temenos, Finacle, Bankable, 10x
Step 6 - Core Banking routes decision back to PP
Again, IF a payment processor is part of the bank’s process, then the authorisation response code will be sent here first, and the PP will then route this back via the network.
Step 7 - PP routes decision to the relevant Network
PP will continue to raise the message back up the chain by sending the authorisation response to the network.
Step 8 - Network routes decision to the Merchant acquirer
The network then sends the response back to the merchant acquiring service.
Step 9 - Merchant terminal displays authorisation response message
And finally, the merchant will display the authorisation response, sometimes with an auth code and sometimes just the ‘Approved’ 😃 or ‘Declined’/’ Failed’ ☹️ message. Once the ‘Approved’ message is received, the merchant knows that the customer has the means to pay, and the customer’s bank has put a block (of the purchase amount) on money in the account.
If the merchant receives a ‘Declined’/’ Error’ message on the terminal or online, it’s usually because one of the checks outlined in Step 5 failed OR due to a timeout/connection issue. In either case, the customer will usually retry the transaction.
Newer retail banking propositions like Monzo and Starling can give immediate notifications to the customer as to why the transaction has not gone through, whether it’s because the account isn’t active or there aren’t enough funds. There are cases, like a suspected fraudulent transaction, where the customer is not allowed to know the reason the transaction has been declined, and this is known as tipping off.
Step 10,11,12 & 13 - Presentment and Settlement
Whilst newer banking propositions with their instant notifications will have you believe that money changes hands instantly, the truth is that it can take a good few days for a merchant payment to be complete, the money to leave a customer's account and be deposited into a merchants bank account (although we are moving towards a world of real-time payments).
Presentment
At a predefined time, usually the end of the day, the merchant acquiring service (see Step 2) is programmed to send the list of authorised transactions, within a defined period, to the relevant networks. The networks will pull this data together, group it by the various issuing banks of the customers, and create something called a 'Presentment' file for each bank.
The Presentment file containing transaction information is then sent to the relevant issuing bank where the customer who made the transaction has their account. The bank will then take the relevant amounts from the customer's account according to the Presentment file and prepare a bulk payment (aggregation of all the individual payments in the file) to be sent back to the network. During this process, the bank will also perform a reconciliation to ensure that the amount the network is requesting aligns with the authorisations on various accounts and payments the core banking platform has given.
Settlement
Once reconciled with the Presentment file, the issuing bank makes the bulk payment to the network’s account. The network will receive multiple bulk payments from the issuing banks based on the Presentment files sent out. Once payment is received, the network will then work out how much is required to be paid to the merchant’s bank based on the initial set of transactions sent from merchant acquirers.
After having worked out how much to pay each merchant’s bank, the network then pays them the aggregate amount owed and once received, the merchant’s bank deposits the appropriate amount directly into the merchant’s account.
So around 2 days after the initial transaction, barring any disputes or errors, the flow is now complete. Money has left the customers account and arrived in the merchant’s account.
Key Players (issuing banks): HSBC, Barclays Bank, Natwest, RBS, Lloyds, Monzo Bank, Starling Bank, Revolut
Express & Explain Yourself 🤯
I know what you’re thinking.
“What a well-visualised and coherent explainer. Now how did this diagram and explainer come together in the first place?”
In 2020, I worked with a client to build a challenger banking proposition in the middle east.
The team was a mix of engineers, designers, delivery, compliance and then myself as product lead. It was also mixed in terms of fintech expertise, with some having experience of building challenger bank and card-based propositions and some completely new to fintech builds of this complexity but still proficient in their respective area.
My role as Product Lead involved:
Creating a roadmap
Structuring the MVP
Setting up requirements
Building wireframes & user journeys for engineers and designers
Creating feature workshops
The complicated process of meeting and selecting the right vendors to support the build and growth of this card-based proposition
So I was fielding a lot of questions. From the different edge cases to include as part of testing, the breadth of the happy and unhappy paths to include as part of onboarding, the authorisation processes and detailed discussions with prospective vendors about the complexity and future roadmap of the product.
Out of these questions during the early part of the project and through various discussions, it was clear there was a gap in knowledge about the end-to-end payment process, which was vital for much of the design, build and vendor selection work, so rather than have individual conversations, I created a reusable diagram to point folks towards and also talk to during vendor conversations.
The diagram and step-by-step explainer gave clarity to design and engineering over the intricate details of the underlying process and made the conversations with vendors much more efficient.
I thought it’d be valuable to share the diagram, so I posted it with the blog on LinkedIn, and the response was overwhelming (although I’m not someone who ‘does it for the likes’). Over 550 likes, nearly 100 positive comments and requests for the high-res image. And many positive remarks from people embedded in fintech from companies like Galileo, Marqeta, Mambu, Visa and Mastercard, and across product, engineering, strategy and innovation roles.
It proved the need for clear explainers with detailed write-ups. A need that still exists.
The Ongoing Product + Technical Proficiency Debate 👨🏽💻
Related to the creation of detailed explainers and why, in my view, people in Product are best place to create resources whether it be Head of Product or a Product Marketeer is the debate around whether Product people need technical expertise
I saw a tweet recently by a ‘Product Guru’ who said:
‘Understanding architecture doesn’t help Product do their job better’.
I’m afraid I have to disagree with this.
That’s not to say I think every CPO or Product Manager should be able to draw up a detailed diagram of how all the services within a product works and how things like microservices and cloud architecture fit together. But at the very least, they should understand things like APIs and Data Structures so they know the limitations and capabilities of the platform and vendors and, at a high level, how the product works under the hood, which can then drive the features and strategy of the product long term.
The Product team also interfaces heavily with Engineering. That relationship is vital at all stages of a company’s life cycle, whether they are just starting out or an established entity. Building a strong and cohesive relationship with Engineering is a lot easier without the technical language barrier.
While the merchant payment process I’ve outlined doesn’t include APIs or specific data structures, the process itself is somewhat technical because with fintech, it’s the nature of the beast, and tech knowledge does help with the logic and structure of putting a diagram like that together.
The most significant reason tech understanding is important is more often than not, people look to the product team for direction and subject matter expertise. They’ll ask questions like, What’s next on the roadmap? Have we got clear requirements? Which vendor will we use or are we building it in-house? What’s the priority? How is the product going to evolve over time? Answering these questions becomes much easier with technical knowledge as it’s a much more rounded understanding of the problem, solution and any technical capabilities or limitations.
In the case of the challenger bank build, technical understanding allowed me to quickly put together the diagram and write-up, ultimately benefiting the wider team and my long-term productivity.
Educating the Educators 🧑🏽🏫
As mentioned, there is still a need for more educational material for builders of the future of financial services. Especially easy to reference and understand the material. Because payments, KYB/KLC, Open Banking, Card issuing etc., are not simple subjects and not everyone building valuable propositions comes from a financial services background.
So when, right after I posted the colourful article on LinkedIn, I was asked by the Marqeta EU team to help shape a card education guidebook designed to upskill and educate card program builders, I jumped at the chance.
It’s a great resource (of course, I would say that) that many across fintech have given me and Marqeta positive feedback about.
But it’s not the only great resource out there. There are several organisations that produce great guides that not only help with SEO, a positive secondary benefit, but primarily help upskill fintech builders and operators.
Demystifying cards: The resource I worked on. A written guidebook covering the history and origins of early cards, reasons for creating a card program, different card types, the costs, opportunities, regulatory considerations, a jargon buster and much more.
API Chronicles: Another Marqeta resource. The last one, I promise. This video series covers a range of topics, from the future of payments and the adoption of crypto to financial inclusion and building customer-centric products featuring guest building and operating in the space.
NB: I am speaking on an edition of the API Chronicles next week covering UX in fintech products with Peter Ramsey from Built for Mars and Mark O’Keefe from Optima Consulting so feel free to sign up here 👀
Open Banking Guidelines: The OBIEs explainers are, as you’d expected, comprehensive and easy to understand. They could have easily just made the APIs available without the supporting guidelines, but the guides with the APIs make it simple for any organisation looking at Open Banking to understand the process, benefits and functionality of the rails.
Tink Presents: This looks like a relatively new video series, and in this first episode, Andrew Boyajian explains Variable Recurring Payments. Varied content is valuable as people learn in different ways, so this short, sharp video is helpful for those new to VRP and can trigger more detailed reading.
GoCardless Guides: These blog style guides are a mix of consumer content (for small businesses looking to take payments) and detailed fintech knowledge which are brilliantly structured.
Lithic Blog: The blog titled ‘Card Issuing, Fintech Education and Product Updates’ has a number of detailed walkthroughs on things like Card Program Management, the chargeback process, fraud detection, AML and more.
Paypr.work - Sandra and the Paypr.work team create easy-to-digest one-pagers across a range of fintech topics from different payment methods and infrastructure to the analysis of fintechs across the globe and everything in between.
Revolut and the Mandela Effect 😶🌫️
The start of this edition mentioned that in-depth resources about the end-to-end process could have mitigated the effects of the Revolut loophole. Hence the deep dive into the card payment process.
Here are a couple of areas that a reference diagram might have helped:
Quickly identifying the points of error: Based on the reported info, the loophole was either at Step 5 (authorisation) or Steps 10-13 (Settlement). Using the diagram as a reference could have made it faster to identify the points of error and close the loophole
Showing the end-to-end process for acceptance and limit testing - Having a clear end-to-end process is very handy for QA testers to use as a guide to create the testing scenarios and create more thorough tests for the authorisation and settlement/clearing processes, potentially spotting and closing the scenario that arose in this case
Highlight reconciliation gaps - This visual could have helped highlight gaps in the reconciliation process of the presentment file & authorisations vs the money leaving Revolut’s accounts
While clear visualised and written processes and reference material certainly would have helped and potentially prevented or sped up the closing of that loophole, there’s no guarantee that criminals wouldn’t have exploited a different loophole or figured out another way to extract funds illegally. Revolut is no different to HBSC, NatWest, Lloyds, Monzo, Starling or any others in that sense.
And in the grand scheme of things, a $20 million loss compared to the $48 billion in payment fraud each year is a 0.04% drop in the ocean.
One way that Revolut is different is the fact that in the same period as the fraud, they also launched in New Zealand and had 26,000 people on the waitlist, and launched their Automated Investing product in the US, neither of which were reported as heavily as the fraud was.
Yes, in general, when it comes to financial services, the news tends to skew towards negative because “a customer was successfully onboarded and has 20 years of great service” is a bit boring. Still, Revolut seems to get the raw end of the media stick more than most.
The Mandela Effect
For those new to the Mandela Effect, here it is in a nutshell.
Do you remember the line from Snow White and the Seven Dwarfs where the Queen asks the mirror who’s the fairest of them all?
It goes, “Mirror, mirror on the wall, who’s the fairest of them all”, right?
Wrong.
The actual line is, “Magic mirror on the wall, who’s the fairest one of all?”.
What about Star Wars: Empire Strikes Back, an iconic film with some iconic lines?
None more iconic than the fight scene between Darth Vader and Luke, where Vader reveals, “Luke, I am your father”.
That’s wrong again.
The actual line from the original was "No. I am your father.", although it was changed in a director's cut because so many people wrongly thought it started with “Luke”.
That’s a great obscure quiz answer, by the way.
These are just two examples of the Mandela Effect. In this phenomenon, a large group of people collectively remembers something inaccurately, often believing that an event or detail occurred differently than it actually did.
The term “Mandela effect” was coined by paranormal enthusiast Fiona Broome in 2010, who noticed that many people shared a false memory of Nelson Mandela dying in prison in the 1980s, even though he was released and went on to become the President of South Africa. This became a prominent example of the phenomenon and gave rise to the name “Mandela effect.”
I think Revolut suffers from the Mandela effect, with a large group of people wrongly assuming the company is rife with scandal, constantly open to fraud and misuse and that they’re “not on the same level as Monzo or Starling”, a line I’ve heard many a time.
Yes, they’ve had C-Suite attrition, and some instances of payment fraud occur on their platform, but not significantly more or worse than other fintechs and certainly not to the degree to which it’s being reported. And in terms of success, they have 30 million customers, 4x more than Monzo. Customer numbers are not the only measure of success but an indicator that Revolut is not the troubled leaky ship people make it out to be. Balanced, proportionate coverage is one way to ensure the effect doesn’t take hold in the long run.
Looping back to the broader point about educational resources, there needs to be more material out there, not just for people currently building in fintech but also for people with great ideas in a valuable problem space.
This doesn’t have to be in a diagram + long-form format like the explainer I put together on the Merchant Payment process and Open Banking. People learn in different ways. So a diverse range of resources from written and visual explainers, podcasts, webinars, white paper reports and events is ideal.
I will continue to do my bit by creating more Under the Hood explainers, which I’ll post here with Card Issuance/Tokenisation & BNPL process flows in the works.
If you have ideas for areas of fintech that you’d like more clarity on or know some great education resources, then add them in the comments or DM me as a centralised list of resources is something I know folks are crying out for.
And if you did learn something and enjoyed this edition, share it with a colleague, friend, family member or Star Wars fan 🙂
Favourite bits of news
Nigel Farage and PEP snowball - This news caused a bit of a divide, with some saying this is an indicator of a broader issue with the application of regulation and some saying that banks are within their rights to refuse a specific account based on an individual being high-risk and falling short of their eligibility criteria. The truth is somewhere in the middle, with clearer communication needed when issues like this arise but also pointing customers to the dispute process. This could be another area where education is needed around Money Laundering regulations, onboarding, and ongoing account management.
Monzo ’to the moon’ with Lunar - Bloomberg broke the news on Wednesday that Monzo is in talks to acquire Nordic fintech Lunar which is likely part of its European expansion plans. In my opinion, Lunar, whose product offering is closer to Revolut’s than Monzo’s and has around 650,000 customers across Denmark, Sweden and Norway and would be a great on-ramp for Monzo into European expansion. It remains to be seen whether 1. This deal will happen, and 2. If it does happen, how the two products will be structured. Lunar branding and product to remain largely as it is with the ‘Monzo’ stamp or a full-scale absorption of the product and brand into Monzo (a bad idea in my product purists' opinion). I’m not an acquisition or fundraising expert, but with the interest rates making it difficult to raise funds, more deals like this will occur in the next few months with larger, more stable organisations looking to buy up organisations that may be struggling to raise debt.