Let's move on! The next section is really important–the transactions! Let's start by looking the first transaction definition:

transaction InitialApplication {
   o String letterId
   --> Customer applicant
   --> Customer beneficiary
   o Rule[] rules
   o ProductDetails productDetails
}

We can see that like assets and participants, transactions are defined with their own keyword:

transaction InitialApplication {

The transaction keyword identifies that what follows is a type definition for a transaction. It's just like the asset or participant keywords. Notice that there isn't an identified by clause in the transaction definition.

This transaction definition represents the initial application made by Alice for the letter of credit. It's quite obvious really, isn't it? A particular instance of a transaction would be created by the application that Alice uses, and we can see the information contained within it:

o String letterId
--> Customer applicant
--> Customer beneficiary
o Rule[] rules
o ProductDetails productDetails

If you look back at Alice's web page, then you'll see all this information: the applicant Alice, the beneficiary Bob, the terms and conditions (rules), and the product details. Notice that the applicant and beneficiary are references to participants, whereas the rules and product details are concepts.

We can see that the transaction has a relatively simple structure but powerfully captures the intention of an applicant (for example, Alice) to apply for a letter of credit to do business with a beneficiary (for example, Bob).