A Technical Guide to Stellar SEP 3 Compliance Protocol

SEP-3 is a protocol for complying with the anti-money laundering laws with financial institutions to know that who is sending money to whom. The compliance protocol handles all these scenarios.

Workflow of SEP-3

Each organization with compliance protocol creates AUTH_SERVER and add in stellar. toml file.
The sender’s financial institution server contacts the receiver financial institution AUTH_SERVER with the AML information.
The receiver’s financial institution responds that are they willing to accept the money and send the AML information

Implementation

AUTH_SERVER

It provides you with a single endpoint where a user can send a compliance request. Once the server is established you need to add the URI into the toml file.

Request

The user has to make a POST request to the receiver’s financial institutions AUTH_SERVER with the following configuration and payload.

Header

Content-type : application/x-www-form-urlencoded

Payload - data and sig

Name	Description
sender	Payment address of the customer
need_info	Flag if the sender needs the receiver’s AML information
tx	Unsigned transaction in XDR format and sequence number must be 0.
attachment	It is the hash of the memo of the txn.

Sig

Sig is the signature of the sender's financial institution of the data block. The receiver should check that signature is valid or not against the public key that is posted in the sender’s toml file.

Response

Following is the response JSON format of the request made to AUTH_SERVER.

Name	Description
info_status	Flag to check that receiver want to share AML information.
tx_status	Flag to check that receiver want to take transaction.
dest_info	JSON of receiver’s AML.

Architecture

Following is the architecture of the SEP-3 workflow.

BankSender fetches BankReceiver’s stellar.toml file

In the first step, the receiver fetches the receiver’s toml file to get the information like AUTH_SERVER, FEDRATION_SERVER, etc to interact with receivers.
BankSender gets the routing info of the receiver so it can build the transaction

Sender makes an HTTP GET request to the federation server and gets the stellar account ID and routing information of the receivers.
BankSender makes the Auth Request to BankReceiver

The sender makes an auth request to the receiver and seeks for the permission to send a transaction to the receiver and receiver’s AML file.
BankReceiver handles the Auth request and sends a response to BankSender

The receiver gets the sender’s domain by splitting the address and fetches the sender’s toml file. The receiver verifies the signature on the auth request with the SIGNING_KEY which present in the toml file of the sender. The receiver sanction checks on the sender by its compliances. The receiver decides to show the AML information if it allows for the transaction of the sender and it sends the dest_info field in the response.
BankSender handles the reply from the Auth request

If AUTH_SERVER returns ‘pending’, the sender makes the request again after a certain number of seconds.
BankSender does AML checks on the receiver

Once the receiver sends dest_info, the sender sanction checks using the receiver’s AML information and if the check passes then it submits the transaction to the stellar network.
BankReceiver handles the incoming payment.

In the last step, the receiver gets the amount credited in the account and sends the transaction back to the network.