Achta's IBAN Validation API Service Overview (achta.com)

Tel: 00 353 (0) 14773295 e: info@achta.com Achta's IBAN Validation API Service Overview (achta.com) Summary At Achta we have built a secure, scalable and cloud based API for SEPA. One of our core offerings is a fully comprehensive IBAN Validation service. Our solution allows for easy integration into any Business Process Flow using simple REST based HTTPS Requests. Registration for the IBAN Validation API To use our API it is simply a matter of getting registered for our service layer. In return we will supply each registered client with a dedicated Encrypted API Key for use in making authenticated requests to our services. We also expect the Referrer header to be provided. The Authorization Header should be : Authorization: AchtaAuth apikeytobeprovided The Referrer Header should be set to : Referer: https://api.achta.com/financeplatform/ Using the IBAN Validation API

Verifying an IBAN is simply a matter of making a HTTPS GET request to https://api.achta.com/financeplatformserices/public/iban?iban=xxxx xx where xxxxx is the IBAN you wish to validate. In return we will respond to authorized requests with a JSON string containing details about the correctness of the IBAN ( see example below) To Authenticate and Authorize each request we expect the encrypted API key from registration to be passed in the Authorization Header of the HTTP request, aswell as the Referrer Header shown below (see example below using curl utility): curl https://api.achta.com/financeplatformservices/public/iban?iban=gb43bofi90212736032696 -H "Referer: https://api.achta.com/financeplatform/" -H "Authorization AchtaAuth MkVBNEMxQzBBODRBODQ5Q0U4RTlEMDNEOTc3Q0E3NEI5Njg2NUUwNTRGQTJFQzVGRUFGMzQ1NT RFRkE4RDYyRDE=" -H "Content-Type: application/json" Response for a Valid IBAN Status 200 OK "INSTITUTION_NAME":"BANK OF IRELAND", "BRANCH_INFORMATION":"Belfast City Branch", "BUILDING":null, "PO_BOX":null, "STREET_ADDRESS1":"4-8 High Street", "STREET_ADDRESS2":null, "STREET_ADDRESS3":null, "STREET_ADDRESS4":null, "POST_CODE":"BT1 2BA", "COUNTY":null, "CITY":"Belfast", "COUNTRY_NAME":"UNITED KINGDOM", "IBAN_BIC":"BOFIGB2BXXX",

"IBAN_NATIONAL_ID":"BOFI902127", "SEPA_ENABLED":true, "DIRECT_DEBIT_ENABLED":true, "BRANCHANDBICFOUND":true, "AccountResult": null, "IBANResult": "CalculatedIBAN":"GB43BOFI90212736032696", "IsValidIBAN":true, "ErrorMessage":"The IBAN seems to be correct.", "CalculatedBranchCode":"902127", "CountryCode":"GB" Response For Invalid IBAN Status 200 OK "INSTITUTION_NAME":null, "BRANCH_INFORMATION":null, "BUILDING":null, "PO_BOX":null, "STREET_ADDRESS1": null, "STREET_ADDRESS2":null, "STREET_ADDRESS3":null, "STREET_ADDRESS4":null, "POST_CODE":null, "COUNTY":null, "CITY":null, "COUNTRY_NAME":null,

"IBAN_BIC":null, "IBAN_NATIONAL_ID":null, "SEPA_ENABLED":false, "DIRECT_DEBIT_ENABLED":false, "BRANCHANDBICFOUND":false, "AccountResult":null, "IBANResult": "CalculatedIBAN":"Unable to Calculate Valid IBAN.", "IsValidIBAN":false, "ErrorMessage":"The IBAN is incorrect, algorithmn returns a remainder which is not 1.", "CalculatedBranchCode":902127, "CountryCode":GB Response for invalid or empty Authorization Header Status 401 Unauthorized "Message":"Authorization has been denied for this request." Using the IBAN Validation API to convert a Sortcode and Account Number to an IBAN Converting an Account Number, SortCode to an IBAN is similar to validating an IBAN except the querystring uses countrycode, sortcode and accountnumber as parameters. Modulus checking is performed on the account number. The sortcode is verified against Swift Reference Data. The countrycode parameter should be a 2 digit ISO country code, i.e. GB for United Kingdom and IE for Republic of Ireland.

It is simply a matter of making a HTTPS GET request to https://api.achta.com/financeplatformserices/public/iban?countryco de=gb&sortcode=ssssss&accountnumber=aaaaaaaa where countrycode=gb or IE, ssssss is the sort code, aaaaaaaa is the accountnumber. In return we will respond to authorized requests with a JSON string containing details about the correctness of the sortcode, account number plus the calculated IBAN ( see example below). To Authenticate and Authorize each request we expect the encrypted API key from registration to be passed in the Authorization Header of the HTTP request (see example below using curl utility): curl https://api.achta.com/financeplatformservices/public/iban?countrycode=gb&sortcode=902127&ac countnumber=36032696 -H "Referer: https://api.achta.com/financeplatform/" -H "Authorization AchtaAuth MkVBNEMxQzBBODRBODQ5Q0U4RTlEMDNEOTc3Q0E3NEI5Njg2NUUwNTRGQTJFQzVGRUFGMzQ1NT RFRkE4RDYyRDE=" -H "Content-Type: application/json" Response for a Valid SortCode and Account Number Status 200 OK "INSTITUTION_NAME":"BANK OF IRELAND", "BRANCH_INFORMATION":"Belfast City Branch", "BUILDING":null, "PO_BOX":null, "STREET_ADDRESS1":"4-8 High Street", "STREET_ADDRESS2":null, "STREET_ADDRESS3":null, "STREET_ADDRESS4":null, "POST_CODE":"BT1 2BA",

"COUNTY":null, "CITY":"Belfast", "COUNTRY_NAME":"UNITED KINGDOM", "IBAN_BIC":"BOFIGB2BXXX", "IBAN_NATIONAL_ID":"BOFI902127", "SEPA_ENABLED":true, "DIRECT_DEBIT_ENABLED":true, "BRANCHANDBICFOUND":true, "AccountResult": "IsValidAccount":true, "ErrorMessage":"The Account for sortcode 902127 and Account 36032696 has passed the modulus check.", "Institution":"BANK OF IRELAND", "IBANResult": "CalculatedIBAN":"GB43BOFI90212736032696", "IsValidIBAN":true, "ErrorMessage":"The IBAN seems to be correct.", "CalculatedBranchCode":"902127", "CountryCode":"GB" Response For Invalid Sortcode Status 200 OK "INSTITUTION_NAME":null,

"BRANCH_INFORMATION":null, "BUILDING":null, "PO_BOX":null, "STREET_ADDRESS1":null, "STREET_ADDRESS2":null, "STREET_ADDRESS3":null, "STREET_ADDRESS4":null, "POST_CODE":null", "CITY":null, "COUNTRY_NAME":null, "IBAN_BIC":null, "IBAN_NATIONAL_ID":null, "SEPA_ENABLED":false, "DIRECT_DEBIT_ENABLED":false, "BRANCHANDBICFOUND":false, "AccountResult":null, "IBANResult": "CalculatedIBAN":null, "IsValidIBAN":false, "ErrorMessage":"No record could be found for branch code 902121. Are you sure it is correct?", "CalculatedBranchCode":null, "CountryCode":null Response for a Valid SortCode and Invalid Account Number "INSTITUTION_NAME":"BANK OF IRELAND", "BRANCH_INFORMATION":"BELFAST CITY BRANCH",

"BUILDING":null, "PO_BOX":null, "STREET_ADDRESS1":"4-8 High Street", "STREET_ADDRESS2":null, "STREET_ADDRESS3":null, "STREET_ADDRESS4":null, "POST_CODE":"BT1 2BA", "COUNTY":null, "CITY":"BELFAST", "COUNTRY_NAME":"UNITED KINGDOM", "IBAN_BIC":"BOFIGB2BXXX", "IBAN_NATIONAL_ID":"BOFI902127", "SEPA_ENABLED":false, "DIRECT_DEBIT_ENABLED":false, "BRANCHANDBICFOUND":true, "AccountResult": "IsValidAccount":false, "ErrorMessage":"The Account for sortcode 902127 and Account 36032697 has failed the modulus check.", "Institution":null, "IBANResult": "CalculatedIBAN":"Unable to Calculate Valid IBAN.", "IsValidIBAN":false, "ErrorMessage":"The IBAN is incorrect, algorithmn returns a remainder which is not 1.", "CalculatedBranchCode":null, "CountryCode":null

Response for invalid or empty Authorization Header Status 401 Unauthorized "Message":"Authorization has been denied for this request." Release Management Procedures Our team has developed many enterprise applications that have been implemented in numerous corporate environments. Our success has been built on a rigorous approach to software development and implementation. We have incorporated these practices into our cloud based offering. The IBAN validation service operates on a continuous integration pipeline. Once a change is packaged our application is deployed to the staging environment in Windows Azure where we will apply our rigorous QA methodology to ensure everything is functioning as expected. The staging environment is a replica of the production environment, except that it can only be accessed with an obfuscated (GUID-based) URL that is generated by Windows Azure. Once the QA team our satisfied then the new code will be promoted into the production environment. The deployment uses a method called Virtual IP (VIP) this essentially allows us to perform an IP swap which reduces the risk of anything going wrong with an additional deployment. The advantages of this approach are clear, in that we can test out our changes in a production environment prior to pushing them into service. Furthermore, we can also instantly rollback to the previous state with ease in case of an unforeseen event.

IBAN Validation Contract Change Procedures It is highly unlikely that our IBAN Validation contract will change, it is a settled format. Any additional elements added to the contract will be nonbreaking, so clients will continue to work without requiring amendments. If a breaking change to the contract is required, a deprecation policy will come into effect. This means we will run two versions of the API side by side. This will give clients the opportunity to take advantage of the new API in their respective development environments while still running with our original API in production. We will only switch off the old API when all clients have happily migrated. There will be periodic updates to our database to keep our application in sync with SWIFT, these will be online updates and will be done "Outside of Business Hours", and will not have any impact on service. If a situation arises were an outage is necessary, advance notice will be given to all Achta clients to allow them to prepare appropriately. IBAN API Virtual Application Isolation To reduce the surface area impact of updates and changes, our IBAN Validation API is hosted as a standalone virtual application, meaning that changes to other functional elements within the ACHTA domain will have no impact on the IBAN Validation codebase. Load Balanced Web Farm The ACHTA platform API is a completely stateless RESTful Service that is deployed in a load balanced web farm with elastic scalability in Windows Azure's North Europe Region which is based in Dublin, Ireland. In the event of a server going down, service will still be able to continue while the fallen server is recovered. Our solution is also elastically scalable, so we can instantly bring online new load balanced instances to meet demand from clients. (see Physical Architecture of Achta Cloud App below)

Service Redundancy Each layer of the Windows Azure platform infrastructure is designed to continue operations in the event of failure, including redundant network devices at each layer and dual Internet service providers at each datacentre. Failover is in most cases automatic (requiring no human intervention), and the network is monitored by the Network Operations Center 24x7 to detect any anomalies or potential network issues. Datacentre Redundancy The Windows Azure platform runs in multiple datacentres around the world. This means we can disperse our data in Windows Azure SQL Databases securely to multiple datacentres. In the event of a catastrophic failure involving an entire datacentre, we could deploy the application at a backup location with the click of button.

Database Redundancy Our solution uses SQL Azure for data storage and retrieval, this provides us with an extremely robust failover and fault tolerant platform to prevent service outages. Windows Azure SQL Database mitigates outages due to failures of individual devices, such as hard drives, network interface adapters, or even entire servers. Data durability and fault tolerance is enhanced by maintaining multiple copies of all data in different physical nodes located across fully independent physical sub-systems such as server racks and network routers. At any one time, Windows Azure SQL Database keeps three replicas of data running one primary replica and two secondary replicas. Windows Azure SQL Database uses a quorum based commit scheme where data is written to the primary and one secondary replica before we consider the transaction committed. If the hardware fails on the primary replica, the Windows Azure SQL Database detects the failure and fails over to the secondary replica. In case of a physical loss of the replica, Windows Azure SQL Database creates a new replica automatically. Therefore, there are at least two physical transactionally consistent copies of your data in the data center. The following diagram illustrates how Windows Azure SQL Database keeps three replicas in the physical server racks in the data center.

In addition to the redundant replicas, Windows Azure SQL Database maintains internal copies of data for the last 14 days within the datacentre. These copies provide a safe guard against simultaneous or catastrophic hardware and system failures. Infrastructure Level Security Windows Azure gives our application a strong level of security. The Windows Azure platform is designed to provide Defense in Depth, reducing the risk that failure of any one security mechanism will compromise the security of the entire environment. The Defense in Depth layers include: Filtering Routers: Filtering routers reject attempts to communicate between addresses and ports not configured as allowed. This helps to prevent common attacks that use drones or zombies searching for vulnerable servers. Although relatively easy to block, these types

of attacks remain a favorite method of malicious attackers in search of vulnerabilities. Filtering routers also support configuring back end services to be accessible only from their corresponding front ends. Firewalls: Firewalls restrict data communication to (and from) known and authorized ports, protocols, and destination (and source) IP addresses. Cryptographic Protection of Messages: TLS with at least 128 bit cryptographic keys is used to protect control messages sent between Windows Azure datacenters and between clusters within a given datacenter. Customers have the option to enable encryption for traffic between end users and customer VMs. Software Security Patch Management: Security patch management is an integral part of operations to help protect systems from known vulnerabilities. The Windows Azure platform utilizes integrated deployment systems to manage the distribution and installation of security patches for Microsoft software. Monitoring: Security is monitored with the aid of centralized monitoring, correlation, and analysis systems that manage the large amount of information generated by devices within the environment, providing pertinent and timely monitoring and alerts. Network Segmentation: Microsoft uses a variety of technologies to create barriers for unauthorized traffic at key junctions to and within the datacentres, including firewalls, Network Address Translation boxes (load balancers), and filtering routers. The back-end network is made up of partitioned Local Area Networks for Web and applications servers, data storage, and centralized administration. These servers are grouped into private address segments protected by filtering routers. Physical Security Physical security goes hand-in-hand with software-based security measures, and similar risk assessment and risk mitigation procedures apply to both. Windows Azure platform services are delivered to customers through a network of global datacentres, each designed to run 24 x 7, and each employing various measures to help protect operations from power failure, physical intrusion, and network outages. These datacentres are compliant

with applicable industry standards for physical security and reliability; managed, monitored, and administered by Microsoft operations staff; and geographically dispersed. Microsoft uses highly secured access mechanisms, limited to a small number of operations personnel, who must regularly change their administrator access passwords. Datacentr eaccess, and authority to open datacenter access tickets, is controlled by the network operations director in conjunction with local datacentre security practices. Application Level Security At an application level we have a completely stateless service API that uses industry standard HTTPS protocol for encryption of requests. Our client API Keys are strongly encrypted with our secret key and a Keyed Hash Algorithm HMACSHA256 which computes a 256 bit output hash.