---
# System prepended metadata

title: Conclusion

---

<img style="max-width: 220px; margin: 30px 0;" src="https://i.imgur.com/J7uPsho.png" />


> Insights to money flow within the app.

<br />

In the following document, we will outline how the application will solve 3 main things: 
- How it Works
- Bank Process
- Deposits
- Transfers
- Payouts (Withdrawals)

<br />


MOBILE PAYMENTS

![](https://i.imgur.com/o7oAaEQ.png)

RETAIL PAYMENTS

![](https://i.imgur.com/EH3Fx5Y.png)

## Bank Process

You will need to contact an acquiring bank. Each major bank will generally have a separate card acquiring arm. So here in the UK we have (eg) Natwest bank, which uses Streamline (or Worldpay) as its acquiring arm. In total even though we have scores of major banks, they all end up using one of five or so card acquirers.

Happily, all UK card acquirers use a standard protocol for communication of authorisation requests, and end of day settlement. You will find minor quirks where some acquiring banks support some features and have slightly different syntax, but the differences are fairly minor. The UK standards are published by the Association for Payment Clearing Services (APACS) (which is now known as the UKPA). 

The standards are still commonly referred to as APACS 30 (authorization) and APACS 29 (settlement), but are now formally known as APACS 70 (books 1 through 7).
Although the APACS standard is widely supported across the UK (Amex and Discover accept messages in this format too) it is not used in other countries - each country has it's own - for example: Carte Bancaire in France, CartaSi in Italy, Sistema 4B in Spain, Dankort in Denmark etc. An effort is under way to unify the protocols across Europe - see EPAS.org


Communicating with the acquiring bank can be done a number of ways. Again though, it will depend on your region. In the UK (and most of Europe) we have one communications gateway that provides connectivity to all the major acquirers, they are called TNS and there are dozens of ways of communicating through them to the acquiring bank, from dialup 9600 baud modems, ISDN, HTTPS, VPN or dedicated line. Ultimately the authorisation request will be converted to X25 protocol, which is the protocol used by these acquiring banks when communicating with each other.
In summary then: it all depends on your region.
Contact a major bank and try to get through to their card acquiring arm.


Explain that you're setting up as a payment service provider, and request details on comms format for authorization requests and end of day settlement files
Set up a test merchant account and develop auth/settlement software and go through the accreditation process. Most acquirers help you through this process for free, but when you want to register as an accredited PSP some will request a fee.
you will need to comply with some regulations too, for example you may need to register as a payment institution

Once you are registered and accredited you'll then be able to accept customers and set up merchant accounts on behalf of the bank/s you're accredited against (bearing in mind that each acquirer will generally support multiple banks). Rinse and repeat with other acquirers as you see necessary.


## Deposits

Deposits would be initiated using an existing payment processor available in the region. This would drastically affect both development time and even more required paperwork and an overall 'offline hassle'. 

Along with it, we can  look into using MTN (mobile money) and direct bank transfers for deposits as well.

After the initial phase, we can look into options of 'becoming' a payment processor ourself by either partnering up with a bank (easier), or becoming a financial institution (harder). This would allow us to earn commision on deposits as we will on transfers, but we strongly suggest leaving something like that for a second phase of the project as it would affect the project timeline by at least 3 to 4 times.

<br />

## Transfers

Once the deposit has been made, we are officially in the posession of the funds and every future transfers (peer to peer / peer to business) are happening exclusively digitally - this means no money is actually being moved anywhere, it remains in our 'escrow' account until a withdrawal. This drastically reduces operation cost while allowing us to charge commision on every transaction that doesn't cost us anything.

<br />

## Payouts (Withdrawals)

Once a user requests a withdrawal, the money will be transfered manually to their bank account within 2 to 3 days. On a later stages, we may look into a solution of completely automating this (again by either partnering up with a bank or becoming a financial institution ourselves), but for the initial phase manual payouts should be more than sufficient as they, on one hand, minimize development time and startup efforts, and on the other don't require more than an agent or two to make the transfers while at the same time check the fraudent withdrawals since services like these can offen be used for money laundering (eg. making a deposit followed by immediate withdrawal or a withdrawal without 'moving' the money to other legitimate users).

<br />

# Conclusion

The system as described above objectively wouldn't be that dificult to get up and running and would require almost no investment in terms of operation.

