Before we start building our project, let's understand the journey of a payment request as it moves across our remittance platform. We'll also do a deep dive into the various components and modules. This will give you a good understanding of the functionality of each module when we are building our platform. For this example, consider Bank A to be the sending bank, that is, the bank that is sending the remittance and Bank B to be the bank that is receiving the payment.

The payment request begins with the customer logging into a banking portal. Typically, they'll enter the beneficiary's name, their account name, a beneficiary bank identifier code, such as a SWIFT BAN number, the amount to send, and the currency in which the payment will be credited to the beneficiary. In our blockchain remittance app, the customer's account number and SWIFT BAN number are replaced by a user-friendly ID that looks like an email ID. Thus, to send the payment to a customer called Stephen at Bank A, I only need to provide his friendly ID, which will look something like Stephen*banka.com. The first part of the ID is a unique identifier, while the second part after the asterisk indicates the domain, typically a domain controlled by the Bank A. When a payment request is to be sent, our remittance app automatically communicates with the banka.com domain and fetches Stephen's bank account number, customer number, and any other details that may be required for the payment to be processed.

After the remitter enters the beneficiary details, they need to enter the amount to be transferred and the destination currency, that is, the currency in which the beneficiary will be credited. Typically, banks and other FIs provide internal conversion rates for converting the source currency, that is, the currency in which the sender initiates a transaction to the destination currency. Sometimes, you can get a rate from an external market maker who does the conversion for the banks. In the Stellar network, you can actually set up a market maker of your own. (We'll be looking at this in Chapter 9, Developing a Currency Trading Exchange for Market Making on Currency Exchanges). In our project, to keep things simple, we'll assume the source and the destination currency are both US dollars, but you can easily integrate an API for conversion rates.

Lastly, they may need to provide identification details such as the name, address, date of birth, and so on for AML/KYC purposes. In our platform, we'll automatically fetch these details from the User Database. This means that the sender does not need to fill in these details explicitly. The customer clicks on submit to submit the payment request.

On clicking submit, the payment request is posted to the Bank A bridge server module. The Bank A bridge server carries out a series of steps:

1. First, it checks with Bank B and confirms whether a user exists with the beneficiary friendly ID that was entered in the payment request. If a user exists, Bank B returns the beneficiary's payment routing details (internal account number, internal customer number, Stellar account ID, and so on) to the bridge server. These details will be used to build the payment transaction that we will submit to the blockchain network. This metadata will help the receiving bank identify the customer that the payment is intended for.

2. Next, the bridge server of Bank A forwards the payment request to the compliance module of Bank A. The compliance module of Bank A checks the details of the sender and confirms if they are sanctioned to send a cross-border remittance – that is, the customer is not blacklisted – and fetches the KYC details of the sender from the internal user database. The compliance module of Bank A then communicates with the compliance module of Bank B, which is the receiving bank, and forwards the KYC details of the remitter/ sender.
3. The compliance module of Bank B receives the sender's details and carries out internal sanctions checks. Sanction checks are carried out to check whether the sender or the financial institution sending the transaction is blacklisted. It also verifies whether the beneficiary can receive the payment, that is, that the beneficiary is not blacklisted. If everything is in order, the compliance module of Bank B gives the go-ahead to Bank A to initiate the remittance transaction. If required, the compliance module of Bank A will also share the KYC details of the receiver/beneficiary with Bank A if required. These KYC details are typically the name, address, and date of birth of the beneficiary.
4. After the compliance module of Bank A gets the go-ahead from the compliance module of Bank B, it relays the go-ahead message to the bridge server of Bank A. The bridge server submits the payment request to the Stellar blockchain network. Typically, the request contains the sender's Stellar account ID, the receiver's Stellar account ID, the metadata to identify the customer (customer ID, account number, and so on), the currency being transferred, and the amount being transferred. Stellar account IDs are similar to Ethereum accounts or Bitcoin addresses. They are public keys and have a linked secret key that is used to sign the transactions that are being submitted to the network. In our remittance model, only the financial institution has a Stellar account ID, on the blockchain network. All the customers of a financial institution are mapped to this account ID. This is why we need to provide the metadata to identify the customer the payment is intended for. This model allows us to cut down on the cost of managing multiple public-private keys and tracking multiple accounts.
5. Once the payment has been submitted to the network, it is broadcasted to all the nodes in the network, including the node to which Bank B, the receiving bank, is connected. The bridge server of the receiving bank, Bank B, is constantly listening for payments to the bank's Stellar account. Upon receiving a payment, it carries out a series of steps. First, it checks whether the compliance handshake was carried out for the payment request. Next, it checks the beneficiary that the payment is intended for and if the beneficiary is sanctioned to receive the payment. If all the checks are passed, the amount is credited to the beneficiary's account. The beneficiary can now log into the bank portal and view the payment. The bank user can log into the portal and see the KYC/AML details of the received payment. That ends our payment flow.

This should give you an idea of how the end-to-end remittance flow works and how our app will function. Now, let's start working on the project. We'll be carrying out the following steps to set up and build the entire project:

1. Set up a private test Stellar network for development.
2. Create the USD asset, representing the US dollar asset that will be transferred.
3. Create the Stellar account IDs for Bank A and Bank B on the network and add a USD balance to them to try out remittances.
4. Set up local domain redirection for the banka.com and bankb.com domains so that we can try out the friendly ID resolution (federation) service for customers.
5. Set up the apache2 server that will host a TOML file. This TOML file will guide incoming requests to the bridge, compliance, and federation servers being run by the bank.
6. Set up the federation service or friendly ID resolution service for Bank A and Bank B.
7. Set up the compliance module for Bank A and Bank B that will handle all incoming and outgoing compliance requests.
8. Set up the bridge server for Bank A and Bank B that will be the bank portal's interface with the Stellar network.
9. Set up a callback server. As the name suggests, this will implement webhooks that can be invoked when a payment is received or when compliance data needs to be verified with the internal bank database.
10. Build a bank portal and backend service in React that will allow the customers and the bank to interact with the Stellar network and submit and receive payments. The bank user can also view the KYC details of received transactions.

We have a long road ahead of us! Let's get started with the network setup.