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.