Architecture

Anchors are entities that people trust to hold their deposits and issue credits into the XDBchain network for those deposits. All money transactions in the XDBchain network (except XDB) occur in the form of credit issued by anchors, so anchors act as a bridge between existing currencies and the XDBchain network. Most anchors are organizations like banks, savings institutions, farmers’ co-ops, central banks, and remittance companies.

Before continuing, you should be familiar with:

• Issuing assets, the most basic activity of an anchor.
• Federation, which allows a single XDBchain account to represent multiple people.
• Compliance, if you are subject to any financial regulation.

Account Structure

As an anchor, you should maintain at least two accounts:

• An issuing account used only for issuing and destroying assets.
• A base account used to transact with other XDBchain accounts. It holds a balance of assets issued by the issuing account.

Create them on the test network using the laboratory or the steps from the “get started” guide.

For this guide, we’ll use the following keys:

Detail	Code
Issuing Account ID	GAIUIQNMSXTTR4TGZETSQCGBTIF32G2L5P4AML4LFTMTHKM44UHIN6XQ
Issuing Seed	SBILUHQVXKTLPYXHHBL4IQ7ISJ3AKDTI2ZC56VQ6C2BDMNF463EON65U
Base Account ID	GAIGZHHWK3REZQPLQX5DNUN4A32CSEONTU6CMDBO7GDWLPSXZDSYA4BU
Base Seed	SAV75E2NK7Q5JZZLBBBNUPCIAKABN64HNHMDLD62SZWM6EBJ4R7CUNTZ

Customer Accounts

There are two simple ways to account for your customers’ funds:

1. Maintain a XDBchain account for each customer. When a customer deposits money with your institution, you should pay an equivalent amount of your custom asset into the customer’s XDBchain account from your base account. When a customer needs to obtain physical currency from you, deduct the equivalent amount of your custom asset from their XDBchain account.

   This approach simplifies bookkeeping by utilizing the XDBchain network instead of your own internal systems. It can also allow your customers a little bit more control over how their account works in XDBchain.

2. Use federation and the memo field in transactions to send and receive payments on behalf of your customers. In this approach, transactions intended for your customers are all made using your base account. The memo field of the transaction is used to identify the actual customer a payment is intended for.

   Using a single account requires you to do additional bookkeeping, but means you have fewer keys to manage and more control over accounts. If you already have existing banking systems, this is the simplest way to integrate XDBchain with them.

You can also create your own variations on the above approaches. For this guide, we’ll follow approach #2—using a single XDBchain account to transact on behalf of your customers.

Data Flow

In order to act as an anchor, your infrastructure will need to:

• Make payments.
• Monitor a XDBchain account and update customer accounts when payments are received.
• Look up and respond to requests for federated addresses.
• Comply with Anti-Money Laundering (AML) regulations.

Stellar provides a prebuilt federation server and regulatory compliance server designed for you to install and integrate with your existing infrastructure. The bridge server coordinates them and simplifies interacting with the XDBchain network. This guide demonstrates how to integrate them with your infrastructure, but you can also write your own customized versions.

Making Payments

When using the above services, a complex payment using federation and compliance works as follows:

1. A customer using your organization’s app or web site sends a payment using your services.
2. Your internal services send a payment using the bridge server.
3. The bridge server determines whether compliance checks are needed and forwards transaction information to the compliance server.
4. The compliance server determines the receiving account ID by looking up the federation address.
5. The compliance server contacts your internal services to get information about the customer sending the payment in order to provide it to the receiving organization’s compliance systems.
6. If the result is successful, the bridge server creates a transaction, signs it, and sends it to the XDBchain network.
7. Once the transaction is confirmed on the network, the bridge server returns the result to your services, which should update your customer’s account.

Receiving Payments:

When someone is sending a transaction to you, the flow is slightly different:

1. The sender looks up the XDBchain account ID to send the payment to based on your customer’s federated address from your federation server.
2. The sender contacts your compliance server with information about the person sending the payment.
3. Your compliance server contacts three services you implement:
   1. A sanctions callback to determine whether the sender is permitted to pay your customer.
   2. If the sender wants to check your customer’s information, a callback is used to determine whether you are willing to share your customer’s information.
   3. The same callback used when sending a payment (above) is used to actually get your customer’s information.
4. The sender submits the transaction to the XDBchain network.
5. The bridge server monitors the XDBchain network for the transaction and sends it to your compliance server to verify that it was the same transaction you approved in step 3.1.
6. The bridge server contacts a service you implement to notify you about the transaction. You can use this step to update your customer’s account balances.

While these steps can seem complicated, Stellar’s bridge, federation, and compliance services do most of the work. You only need to implement four callbacks and create a stellar.toml file where others can find the URL of your services.

In the rest of this guide, we’ll walk through setting up each part of this infrastructure step by step.