Proposal - HackMD

# Proposal [TOC] ## Executive Summary The objective of this proposal is to introduce a digital banking system that enables BBK to adapt more rapidly to customer needs and stay competitive in the ever-evolving financial landscape. This innovative system will streamline operations, enhance the customer experience, and accelerate the delivery of new products and services. As part of this transformation, we will renew BBK's mobile and web banking applications, ensuring a modern, user-friendly experience for their customers. Additionally, we will revamp customer-facing business processes, such as customer onboarding and loan origination, to provide more efficient and seamless interactions. To achieve these goals, we will leverage state-of-the-art technologies and methodologies, working closely with all relevant stakeholders, including customers, employees, and partners. The proposed digital banking system will provide a comprehensive suite of features and functionalities tailored to BBK's customers' diverse requirements. It will distinguish itself from existing solutions through its speed, flexibility, and user-centric design. By implementing this new system, BBK will enjoy numerous benefits, such as increased efficiency, higher customer satisfaction, and a more agile response to market trends. The project will require investments in resources, including technical expertise, infrastructure, and software. However, these costs will be justified by the long-term value the system will bring to BBK. We plan to deliver the first outcomes by the end of the year, demonstrating our commitment to rapid progress and setting the stage for full deployment. The proposed timeline for the project spans from initial planning to full deployment, ensuring a smooth transition and minimizing disruption to existing operations. Our commitment to this digital transformation will position BBK for success in the dynamic world of banking and secure its reputation as a forward-thinking financial institution. ## 1 - Introduction Turkey has emerged as a frontrunner in digital banking innovation across the Middle East and North Africa, thanks to significant investments by Turkish banks in cutting-edge technology and steadfast support from regulatory authorities. This conducive environment has cultivated a thriving fintech ecosystem, teeming with inventive startups and fintech companies. Our aim is to create a hub that harnesses Burgan Bank Turkey's expertise in digital banking, fintech, and advanced technologies to bolster efficiency, minimize costs, and foster innovation. Establishing this hub positions the group to attract elite technology and digital talent while simultaneously benefiting from a rich and diverse fintech ecosystem. We have carried out a series of site visits and workshops with BBK to assess the compatibility of BBK's requirements with BBT's areas of expertise and investment. Key insights include: * BBT's next-generation technology stack aligns with BBK's modernization plan. * Consensus on a high-level solution architecture and preliminary timeline. * Initial focus on systems of engagement, with an emphasis on * Mobile and Internet banking. * Account Opening, Loan Origination, KYC and similar customer facing processes and agreed on the following design principles * Develop solutions for both physical and digital channels on a unified platform, facilitating seamless experiences while also allowing for channel-specific customizations. * Employ reusable components to craft adaptable solutions suitable for various countries, products, and regulations. * Utilize a consistent technology stack to build user interfaces, promoting component reuse and a cohesive experience for employees and customers. * Leverage an enhanced technology stack, architecture, and DevOps practices to expedite software production, reduce time to market, and increase the number of concurrently deliverable projects. * Employ a next-generation technology architecture that optimizes computing resource usage and provides on-demand scalability to accommodate growing customer demands. This proposal further details the solution architecture and initial scope of work to be conducted and proposes an executable plan. ## 2 - Project Scope And Development Aproach ### 2.1 Loan, CRE And Insurance Workflows #### 2.1.1 Functional Scope | Domain | Workflows | Description | | -------------- | ---------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Consumer Loans | Consumer Loan Housing Loan Buyout Loan Loan against Term Deposit Loan with CC TopUp Loan Auto Loan | The entire loan workflows will be developed end to end with all aspects of the loan disbursement process starting from the branch CRO to CQIT status. The development will include all display and data entry screens, existing internal and external service integrations and scoring algorithms. | | CRE | New Customer Onboarding | The registration workflow of a new customer will be developed end to end by phone validation over OTP and AML verifications. After the necessary approvals and controls, customer registration and customer accounts will be created in the core banking system. In addition, customer cards will be created in the PowerCard system. | | CRE | KYC Update | The KYC Update workflow will be developed end-to-end including phone validation over OTP and, AML controls and necessary data updates in the core banking system. | | Credit Card | Application | Credit Card issuing workflow will be developed end to end from starting with Card Application Form to issuing card on PowerCard system Including all scoring and control states. | | Insurance | Loan | The insurance workflow will be developed end-to-end as a sub-flow of the credit workflow. | | Insurance | Credit Card | The insurance workflow will be developed end-to-end as a sub-flow of the card generation workflow. | With the use of Workflow engine, it will be possible to add a new control or processing state to the existing steps such as CRO, CVU Approval, CQIT without the need for any changes or the deployment of any application. Changing existing forms in the workflow or adding new forms to any workflow can only be updated via configuration with the dynamic forms subsystem. Thus, additional fields or new workflow transitions can be developed and deployed quickly. Decision trees used in areas such as scoring will be prepared with the visual DMN subsystem instead of code and can be modified and activated by analysts or users of the responsible business unit, if desired. Departments (such as CVU, CQIT) and individuals (such as AGM, SGM) that take part in more than one process (such as Auto Loan, Mortagage, Personnel Loan) will be able to follow up all the tasks assigned to them on a single list in the application and take over and complete the relevant works. Thus, when a task is added with a new process, employees will follow their new tasks on the worklist without following an additional interface. Key development areas per process; #### 2.1.2 Process Design For the process to be developed, first of all, the process steps and the transitions between the steps will be determined. Within the specified transitions, necessary integrations, access to internal and external data sources, calculations are defined. Than defined all implementations and integrations requirements are developed. Integration tests will be developed specifically for each developed process, covering the entire life cycle of the process. > What to expect from BBK; > - Providing detailed analysis per process including workflow,calculations, internal and external services used. #### 2.1.3 Form and View UI Design Data entry forms will be designed for all data to be entered by users in the process. For record view, user interface designs and developments of the record data and all related datasets will be made. > What to expect from BBK; > - Providing detailed data entry and display forms per state and transition. #### 2.1.4 Identity And Access Management Integration The specified operation users and roles will be defined. Task pool, transition and data monitoring screen authorizations will be made for the defined roles. > What to expect from BBK; > - Providing detailed data entry and display forms per state and transition. ### 2.2 Mobile And Web Internet Banking #### 2.2.1 Functional Scope #### 2.2.1.1 User Management & Authentication | Feature | Description | | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | New User | User must be able to register to the application in order to to be able to use the application. User will enter nationalId, ATM Debit card number, Pin and captcha and will be validated using MW services. If validation success it will proceed to the complete registration screens where she will be able to set login password, security questions, security seal combinations and an OTP to complete the registration. OTP will be recieved on both email and Mobile (contact details will be fetched from Middleware repository) | | Biometric Login | User must be able to set biometric login in order to be able to biometric data for login. User will enter login id, security question answer and security seal combination and then login password to register biometric login. | | Password Login | User must be able to login to the application using nationalId and password. | | Biometric Login | User must be able to login to the application using biometric data. | | OTP | User must enter OTP as second factor in order to complete login action. | | Change Password | User must be able to change her application password. | | Reset Secure Access | User must be able to reset her secure access question and answer. | | Logout | User must be able to log out from the application and terminate the session. | #### 2.2.1.3 Prelogin | Feature | Description | | --------------------- | --------------------------------------------------------------------------------------------------------- | | Book an Appointment | User must be able to book an appointment for a branch by selecting the branch, appointment type and time. | | Offers and Promotions | User must be able to display offers and promotions on prelogin. | | Apply Now | User must be able to apply for a credit card of loan. | #### 2.2.1.3 Dashboard User must be able to display Dashboard after successful login. On Dashboard screen she must be able to display summary informaton and reach to the details of the following features. * Accounts, * Credit cards, * Prepaid Cards, * Loans, * Term Deposits * Statements #### 2.2.1.4 Account Management | Feature | Description | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Account List | User must be able to display her accounts as a list. | | Account Details | User must be able to display details of an account. The details displayed can be differenciate between account types. | | Account Transactions | User must be able to display the transactions of a selected account on the account details screen. | | Statements | User must be able to display account statement as PDF for the selected period / time interval. \* PDF will be generated by MW in Base64 formst. | | Transaction Receipt | User must be able to view receipt of an account transaction as PDF and send it to her registered email address. \* Transaction receipt will be generated and sent MW as PDF file. | | Open an Account | User must be able to open an Account by specifying following details: \* Currency \* Account Name \* View and Approve Account Contract User must be able to display confirmation and result screens after specifying account details. | | Close an Account | User must be able to close an Account by displaying confirmation and result screens. | | Certifcate Request | User must be able to request an account certificate. | | Cheque Book Request | User must be able to request a cheque book. | | Term Deposit List | User must be able to display her time deposits as a list. | | Term Deposit Details | User must be able to display details of a time deposit. The details displayed can be differenciate between account types. | #### 2.2.1.5 Card Management | Feature | Description | | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Credit Card List | User must be able to display her credit cards as a list. | | Credit Card Details | User must be able to display details of a credit card. | | Credit Card Transactions | User must be able to display transactions of a credit card. | | Credit Card Statements | User must be able to display statement of a credit card by selecting month and year information. | | Credit Card Payment - Own Credit Card | User must be able to make payment to a credit card by specifying following details: \* From Account \* Amount Options - Total Debt - Minimum Payment Amount - Other Amount \* Amount Input \* Automatic Payment Order Option User must be able to display confirmation and result screens after specifying transaction details. | | Credit Card Payment - Other Credit Card | User must be able to make payment to an other credit card by specifying following details: \* From Account \* Credit Card Number \* Amount Input \* Automatic Payment Order Option User must be able to display confirmation and result screens after specifying transaction details. | | Credit Card Payment - Auto Pay Registration | User must be able to register to pay her credit card automatically. | | Money Withdrawal | User must be able to withdraw money from a credit card by selecting a credit card, an accoıunt and entering the withdrawal amount. User must display confirmation and result screens after specifying transaction details. | | Credit Card - OTP Confirmation | User must be able to confirm credit card transactions by entering OTP sent to her registered mobile phone number. | | Change Card Pin | User must be able to change her credit card pin. | | Temporary Block | User must be able to block her credit card temporarily. | | Report Lost / Stolen | User must be able to report her credit card that it is lost / stolen. | | Prepaid Card List | User must be able to display her prepaid cards as a list. #### 2.2.1.6 Loan Management | Feature | Description | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Loan List | User must be able to display her loans as a list. | | Loan Details | User must be able to display details of a loan. | | Installment Payment | User must be able to make installment payment to a loan by specifying following details: \* From Account User must be able to display confirmation and result screens after specifying transaction details. | | Close Loan | User must be able to close a loan by paying the remaining amout. \* Calculation of closing amount will be retrieved from MW services. | #### 2.2.1.7 Statements User must be able to display statements of her accounts, loans, credit cards, prepaid cards by searching them. With advanced search users must be able to search statements by selecting dates, last N transactions, amounts etc. #### 2.2.1.8 Money Transfers | Feature | Description | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Between Own Accounts | User must be able to make money transfer between her accounts by selecting the following information. \* From Account among her accounts. \* To Account among her accounts \* Amount | | To Other Burgan Accounts | User must be able to make money transfer to other accounts by selecting / entering the following information. \* Select "From Account" among her accounts. \* Enter "To Account" information / Select a beneficiary - Beneficiary Name & Surname - Account Number \* Select a date - Case future date selected: "Future Money Transfer Order" \* Amount | | To Other Accounts | User must be able to make money transfer to other accounts by selecting / entering the following information. \* Select "From Account" among her accounts. \* Enter "To Account" information / Select a beneficiary - Beneficiary Name & Surname - Bank - Branch - Account Number \* Select a date - Case future date selected: "Future Money Transfer Order" \* Amount | | SWIFT | User must be able to make money transfer to international accounts by selecting / entering the following information. \* Select "From Account" among her accounts. \* Enter "To Account" information / Select a beneficiary - Beneficiary Name & Surname - SWIFT code - IBAN \* Select a date - Case future date selected: "Future Money Transfer Order" \* Amount | | Save A Beneficiary | User must be able to save a beneficiary while doing a money transfer transaction. | | List Beneficiaries | User must be able to list saved beneficiaries, display, edit saved information of each beneficiary or delete a beneficiary. | | Money Transfer Limits | User must be able to display money transfer limits and update them. | | OTP Confirmation | User must be able to confirm money transfer to other account transactions by entering OTP sent to her registered mobile phone number. | #### 2.2.1.9 Payments | Feature | Description | | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | eZpay Link | User must be able to generate an eZpy link and share it so that she can receive payments from others. | | Bill Payment | User must be able to make bill payment by specifying following details: \* Bill Type \* Company Type \* Company Name \* Bill Input Fields (Customer Number, Account Number, Mobile Number) \* Bill List \* Amount (input for prepayment, read-only for bill payment) \* From Account \* Save Beneficiary Option \* Automatic Payment Order Option User must be able to display confirmation and result screens after specifying transaction details. | | Bill Payment to Saved Beneficiary | User must be able to make bill payment by specifying following details: \* Saved Beneficiary Selection \* Bill Selection \* Amount (input for prepayment, read-only for bill payment) \* From Account \* Automatic Payment Order Option User must be able to display confirmation and result screens after specifying transaction details. | | Display Instructions | User must be able to list saved instructions. | | Edit / Delete Instructions | User must be able to edit / delete saved instructions. | #### 2.2.1.10 Applications | Feature | Description | | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Credit Card | User must be able to apply to a credit card by selecting the card type, and filling the application form. User display confirmation and result screens after specifying transaction details. | | Loan | User must be able to apply to a loan by filling the application form, selecting the term. User display confirmation and result screens after specifying transaction details. | #### 2.2.1.11 Investment | Feature | Description | | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Maqasa Registration | User must be able to initiate Maqasa registration from the application. | | Exchange Rates | User must be able to display exchange rates with the last update date and time. The following fields should be displayed for each currency: \* Currency Code \* Currency Name \* Buy Rate \* Sell Rate | | Currency Converter | User must be able to convert currencies by selecting source and destination currencies and entering sourse or destionation currency amount. | | Buy / Sell Foreign Currency | User must be able to buy and sell foreign currencies by specifying following details: \* From Account \* Currency of To Account \* To Account \* Amount component available for both source and target currency User must be able to display confirmation and result screens after specifying transaction details. | | Time Deposit Rates | User must be able to display time deposit rates and calculate potential earnings. | | Saving Account Rates | User must be able to display saving account rates and calculate potential earnings. | #### 2.2.1.12 Investment | Feature | Description | | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Maqasa Registration | User must be able to initiate Maqasa registration from the application. | | Exchange Rates | User must be able to display exchange rates with the last update date and time. The following fields should be displayed for each currency: \* Currency Code \* Currency Name \* Buy Rate \* Sell Rate | | Currency Converter | User must be able to convert currencies by selecting source and destination currencies and entering sourse or destionation currency amount. | | Buy / Sell Foreign Currency | User must be able to buy and sell foreign currencies by specifying following details: \* From Account \* Currency of To Account \* To Account \* Amount component available for both source and target currency User must be able to display confirmation and result screens after specifying transaction details. | | Time Deposit Rates | User must be able to display time deposit rates and calculate potential earnings. | | Saving Account Rates | User must be able to display saving account rates and calculate potential earnings. | #### 2.2.1.13 Settings, Profile, Queries & Complaints | Feature | Description | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Notification Settings | User must be able to display and update her notification preferences. | | Profile | User must be able to display her profile details. | | Contact Details | User must be able to display her contact details and update them. | | Queries | User must be able to compose and send email queries to customer service. | | Complaints | User must be able to compose and send issues to Bank Custmer Complaint Unit to register the case with CBK. User must be able to expalin the issues with attacments upload option . | #### 2.2.1.14 General | Feature | Description | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Version Check | Version check must be implemented for version control of the application. | | SSL Pinning | SSL Pinning must be implemented for security of the application. | | Crashlytics | Standard Crashlytics should be integrated to the application. \* Custom events are excluded. | | Language Support | Mobile app should be able to support multiple languages. | | Splash & Tutorial | User should be able to display Splash screen when the application is launched. Also user must be able to display tutorial when the application is launched for the first time. | #### 2.2.2 Mobile and Web Internet Banking UI Design The Mobile and Web UI will be designed by our business partner and our team in strong collaboration with the responsible BBK business and technical digital teams. The design process will be completed by dividing the designed user interfaces into reusable UI components by evaluating existing services. > What to expect from BBK; > - Actively participating in the design process > - Supporting the evaluation of existing banking services > - Ensuring the completion of the design process in the targeted calendar and obtaining the necessary approvals #### 2.2.2 Service Development Services needed within the scope of the project (such as beneficiary services) will be developed. Gateway records for services will be made with security integration and will be made available to channels. > What to expect from BBK; > - Actively participating in the shared services design. > - Supporting gateway and service configuration studies. #### 2.2.3 Mobile and Web Internet Banking UI Web and mobile UI will be developed by our business partner with services and approved designs. A Single Sign-on portal will be developed to allow authentication of applications. > What to expect from BBK; > - Actively participating in the SSO Portal development. > - Supporting Mobile and Web UI development with assuring test services are consumable. * BTech will develop the following applications: * iOS Application * Android Application * BTech will develop mobile applications with iOS and Android using Flutter. These applications will support portrait orientation. * iOS and Android applications will be developed to work properly on OS versions and devices given in the following support scope. * iOS OS Support Scope: * iOS 15.x, iOS 16.x * iOS Device Support Scope: * iPhone 8, iPhone 8 Plus * iPhone X, iPhone XS, iPhone XS Max * iPhone XR * iPhone 11, iPhone Pro 11, iPhone Pro Max 11 * iPhone 12, iPhone Pro 12, iPhone Pro Max 12 * iPhone 13, iPhone Pro 13, iPhone Pro Max 13 * iPhone 14, iPhone Pro 14, iPhone Pro Max 14 * Android OS Support Scope: * API Level 28, 29, 30, 31, 32, 33 * Android 8.x, 9.x, 10.x, 11.x, 12.x * Android Density Support Scope: * hdpi ~240dpi * xhdpi ~320dpi * xxhdpi ~480dpi * xxxhdpi ~640dip * Web Application will be developed with Flutter framework. Web application will be developed to work properly on desktop browser versions given in the support scope: * Chrome – Latest 3 versions * Firefox – Latest 3 versions * Safari – Latest 2 versions * Edge – Lastest 2 versions #### 2.2.4 Grant-Flows Development Multi-factor user authentication flows will be developed to enable customers to access web and mobile internet banking. Also, password reset and claim password processes will be developed. > What to expect from BBK > - Providing the necessary services for the integrations needed in designing the user life cycle (determining the statuses and actions) and performing the actions that ensure the status transition. > - Providing the necessary services to enrich the user and scope information. > - Preparing the analysis of login and claim password processes. #### 2.2.5 Transaction Engine Development Financial transactions will be registered in the transaction engine ensuring that expected controls are met. > What to expect from BBK > - Providing the necessary analysis and services for the integrations needed in designing the financial transactions processes. ### 2.3 Development Methodology Our development approach is Scrum based agile methodology. Key areas in our development are; * **Backlog Management**: Each request to be developed is defined as the smallest possible requirement. Backlog is all of the requirements. Detailed analysis and acceptance criteria are determined for each requirement. The requester and the development team work together in detailing each requirement. * **Development**: During the software development phase, improvements are made by creating a branch for each feature. Each development is merged with pull requests in the main code. Code reviews are performed by the responsible architects during the pull request. The data to be stored is designed relationally with the code first approach and is developed as independent of the database vendor as possible. * **Testing**: We create integration tests for every service and process, including the full lifecycle of processes. This tests are used for load and stress tests, automatic testing while deployment pipeline and testing in pull request process. * **Deployment**: All products or code are deployed fully automated with pipelines. Every deployment pipelines includes automated tests, code quality control and code security control. ## 3 - Solution Architecture ![](https://i.imgur.com/WW6lfbC.png) ### 3.1 Mobile And Web Internet Banking Web and mobile banking will be modernized by leveraging existing services as much as possible. The primary objective is to revamp the infrastructure and appearance of mobile and web banking while retaining current functionality. Web and mobile internet banking frontends will be developed using a UI composition approach. This method involves constructing the user interface by combining various components or modules, rather than designing each screen or page from scratch. Our proposal for the upgraded mobile and web internet banking includes the development of a new mobile app using Flutter, an innovative UI toolkit. Integrating Flutter into our solution offers several significant benefits: Cross-platform Compatibility: Flutter enables the development of a single codebase that can run on multiple platforms, including iOS and Android. This ensures a consistent user experience across different devices, reducing development time and resources needed for platform-specific adjustments. Rapid Development and Testing: Flutter's hot reload feature allows developers to see changes in real-time without having to restart the application. This accelerates the development process and enables quicker iterations, resulting in more efficient deployment of updates and improvements. High Performance: Flutter's architecture is built for high performance, with its rendering engine designed to provide smooth animations and transitions. This ensures a seamless user experience, with minimal lag or disruptions in the app's performance. Customizable UI Components: Flutter's extensive library of widgets allows for the creation of highly customizable and visually appealing UIs. This flexibility enables our developers to design a tailored interface that aligns with our branding and delivers an engaging user experience. Scalability and Maintainability: Flutter's modular structure facilitates easy scaling and maintenance of the mobile app. As our digital banking services expand or evolve, we can effortlessly update the app to meet new requirements or incorporate additional features. In summary, using Flutter for our new mobile app development will not only provide a consistent, high-performance experience across platforms but also streamline the development process, allowing for rapid deployment, customization, and easy scalability of our mobile banking solution. Utilizing a composition approach offers several benefits, such as improving consistency across different screens or pages and making it easier to update the UI in the future. It can also help streamline development by reducing the amount of custom coding required for each screen or page. The solution also provides a unified user authentication infrastructure for customers to use across various digital channels (Mobile, Web, Call Center, Wearable applications, etc.). This means that customers will not need to go through separate authentication processes for each channel they use, as they will be able to use the same login credentials across all channels. In this solution we will use; * **Identity and Access Management(IDM)** secures customer access. In addition, for integration requirements, customers can generate the api keys for direct API access. Allowing customers to generate API keys for direct API access can also provide benefits, such as enabling them to integrate with the system more easily and efficiently. IDM also supports corporate customer delegates, who can use a single set of login credentials to access the system on behalf of their organization. * **Workflow Management Engine** will be used to manage the lifecycle of users in the web and mobile internet banking system, such as deactivating or locking users, from a single point. Additionally, the system will include grant flows for processes such as mobile and web login, as well as claim or password management. * **Contract and Document Verification System** will be used to check contracts related to customers, such as contracts related to digital channels usage and transaction allowing (FX etc.) contracts. * **Transaction Management** will be used to manage cross-cutting concerns related to financial transactions, the system can ensure that these concerns are addressed consistently across all transactions. For example, the system may use fraud detection algorithms or inegrate existing fraud system to identify potentially fraudulent transactions, or may require additional security checks for high-value transactions. ### 3.2 Loan, CRE And Insurance Workflows We will rebuild existing workflows running on the Ultimus BPM using the Workflow Management Engine and improve workflow and user interfaces. All workflows will be designed to enable customers to initiate and monitor their own processes, with the goal of facilitating their integration into digital channels in the future. This implies a focus on customer-centricity, empowering customers to take control of their own experiences and interact with the organization in the way that suits them best. In this solution we will use; * **Identity and Access Management** to secure users' access and proper control. In addition, with this infrastructure, we will be able to include customers and dealers in the processes. In addition, we will enable the secure development of processes that require integration, such as loan sales via e-commerce. * **Workflow Management Engine** to allow visually designing workflows using the industry-standard Business Process Model and Notation (BPMN). This implies that the organization intends to use a well-established and widely used framework to model and manage its workflows, which can help ensure consistency, interoperability, and ease of integration with other systems and tools. And we will enable human task pools at necessary stages to help improve the organization's workflow management capabilities and potentially lead to better operational efficiency and improved customer experience. * **Contract and Document Verification System** will be used to create, sign, collect and control documents that processes needs and also controlling existing documents and contracts to reuse in the processes. ## 4 - Feature And Benefits The proposed digital banking system is designed using a modular, cloud-native architecture built on Kubernetes, ensuring scalability, flexibility, and adaptability. The high-level solution architecture consists of the following components: ### 4.1 Banking IDM & Gateway This component provides OAuth2 compatible authorization and authentication for various user types, including retail, corporate, non-customers, and employees. It supports banking-specific authorization scenarios, ensuring secure access to resources based on user roles and privileges. Key features include: * Support for acting on behalf of multiple institutions * PSD2 compliant customer and provider validation * Conformance with industry-standard OAuth2 specifications * Banking-specific authorization scenarios, such as allowing customers to view only their accounts or limiting a customer representative's access to the data of customers in their portfolio ### 4.2 Workflow Management This component leverages Zeebe® and Form.io® powered workflow engines to manage banking processes, transactions, and user interactions. It supports a combination of state machine and flowchart workflows and integrates with user interfaces for data inputs and management. This component allows users to access all transaction screens, single inbox for manual actions. Additionally, users can view the entire history of data changes and workflow. On the other hand, user interface development for a new workflow can be achieved with only configuration updates without the need for application deployment. Of course, it allows to develop workflow or data specific user interfaces when necessary. Key features include: * Supports asynchronous client communication with SignalR® for a more responsive and convenient user interfaces * With Form.io(r), it provides rapid development of forms that support rich data entries. * Full-text and filtered search configuration for entities make it easy and fast to find a searched record ### 4.3 Contract and Document Verification System This component enables the process-based creation, approval, and management of physical and digital documents, as well as contract information. It integrates tightly with the workflow management system to streamline document collection and manual control activities. It will integrate tightly with the Workflow Management system for document collection and manual control activities. Key features include: * Allows to render Plain Text, HTML, and PDF documents for online and we signing. * Supports process-specific document control set definition and validation * Provides a process and monitoring for re-supplying missing or problematic documents. ### 4.4 Transaction Management This component provides a platform for developing standard customer transactions in alternative channels, ensuring secure and compliant financial transactions. It supports two-step transaction scenarios, multi-factor authentication, and real-time fraud control integration. Key features include: * Seamless integration with real-time fraud control systems * Allows additional customer authentication controls to be performed dynamically with UI routing ### 4.5 Security Overall solution has industry standard advanced security features; * Customizable workflow support for various Strong Customer Authentication (2FA, Mobile Push, Authentication apps) grant flow scenarios. * API access security with roles and privileges integrated with APISIX®. * APISIX® provides rate-limiting and throttling capabilities to prevent overloading of APIs by limiting the number of requests that a client can send within a specified period. It helps to prevent overloading of the server and ensure that the API can handle traffic efficiently and also help to prevent DDoS attacs. * Allows standards-based integration with applications that support OAuth2. * Supports role-specific API keys, per client configurable claims, consent workflows. * Conforms to industry standard OAuth2 specifications * [RFC 6749: The OAuth 2.0 Authorization Framework](https://www.rfc-editor.org/rfc/rfc6749) * [RFC 6750: OAuth 2.0 Bearer Token Usage](http://tools.ietf.org/html/rfc6750) * [RFC 7519: JSON Web Token (JWT)](https://www.rfc-editor.org/rfc/rfc7519) * [RFC 7636: Proof Key for Code Exchange](https://www.rfc-editor.org/rfc/rfc7636) * [RFC 7662: Token Introspection](http://tools.ietf.org/html/rfc7662) * [RFC 7009: Token Revocation](http://tools.ietf.org/html/rfc7009) * [RFC 8252: OAuth 2.0 for Mobile and Native Apps](http://tools.ietf.org/html/rfc8252) ### 4.6 Key Technologies #### Cloud Native Microservice Architecture Cloud native architecture is an approach to designing and building applications that takes full advantage of the cloud computing model. It is a set of best practices and principles for developing, deploying, and scaling applications in the cloud. At its core, cloud native architecture is focused on creating highly scalable, resilient, and portable applications that are designed to run in cloud environments like public, private, or hybrid clouds. It emphasizes the use of containerization, microservices, and DevOps practices to achieve these goals. Some of the key principles of cloud native architecture include: * Containerization: Applications are packaged in lightweight, portable containers that can be deployed and run consistently across different environments. * Microservices: Applications are broken down into smaller, independent services that can be developed, deployed, and scaled independently of each other. * Automation: Infrastructure and deployment processes are automated using tools like CI/CD pipelines to reduce errors and speed up development cycles. * Resilience: Applications are designed to be fault-tolerant and able to recover quickly from failures. * Scalability: Applications are designed to scale horizontally by adding more instances of services to handle increased traffic. * Observability: Applications are designed to be monitored and provide rich telemetry data that can be used to troubleshoot issues and improve performance. Overall, cloud native architecture provides a set of best practices and principles for building applications that are designed to run in cloud environments. It enables organizations to build highly scalable, resilient, and portable applications that can take full advantage of the benefits of the cloud. #### Dapr Dapr (Distributed Application Runtime) is an open-source runtime for building microservices-based applications. It provides a set of building blocks and abstractions that enable developers to focus on building business logic, rather than managing infrastructure. Dapr is cloud-agnostic, meaning it can run on any cloud platform or even on-premises. It supports multiple programming languages and offers a variety of integration options with other services, making it easy to integrate with existing systems. Some of the key features of Dapr include: * State management: Dapr provides a consistent API for managing state across multiple storage solutions, such as Redis, Cosmos DB, and SQL databases. * Pub/Sub messaging: Dapr provides a messaging API that supports a variety of message brokers, such as Kafka, RabbitMQ, and Azure Service Bus. * Service-to-service invocation: Dapr provides a standard API for service-to-service communication, allowing services to call each other without needing to know their network location. * Secrets management: Dapr provides a secure way to store and retrieve secrets, such as passwords and API keys. * Tracing: Dapr provides a distributed tracing system that allows developers to monitor and troubleshoot their applications. Overall, Dapr simplifies the process of building and managing microservices-based applications by providing a set of common abstractions and APIs that work across different cloud platforms and programming languages. It has become a popular choice for developers looking to build scalable and resilient microservices-based applications. #### Apisix AAPIsix is a free, scalable, and cloud-native API gateway developed by the open-source community of Apache. It provides a highly configurable and efficient platform for managing and routing API traffic, as well as monitoring and analyzing performance metrics. APIsix is designed to handle large volumes of API requests, making it ideal for organizations with high-traffic API services. It provides a flexible and extensible architecture that allows users to customize and add new functionality as needed. Some of the key features of APIsix include load balancing, service discovery, rate limiting, authentication, and access control. It also offers a plugin system that allows users to extend and modify its functionality, as well as integration with popular service meshes like Istio. APIsix is built using the Nginx web server and Lua scripting language, which provides a powerful and efficient platform for handling API requests. It also provides a RESTful API for configuring and managing the gateway, making it easy to integrate with other systems and automate management tasks. Overall, APIsix is a powerful and flexible API gateway that can be used to manage and route high-traffic API services in a scalable and efficient manner, and it has become a popular choice for organizations looking for a reliable and cloud-native API gateway solution. #### Zeebe Zeebe is a free and open-source workflow engine for microservices orchestration. It was developed by Camunda and was first released in 2017. Zeebe allows users to define and execute business processes using BPMN 2.0, a widely used standard for modeling business processes. Zeebe is designed to handle high-throughput, low-latency workflows that can be distributed across multiple nodes in a cluster. It supports horizontal scaling, fault tolerance, and provides high availability. Zeebe also offers a number of features that make it easier to integrate with other systems, such as support for various message brokers and cloud providers. Overall, Zeebe is a powerful tool for developers who need to implement complex workflows in their microservices architecture. It enables them to create scalable, fault-tolerant, and highly available systems that can handle large volumes of workloads. #### Flutter Flutter is a free and open-source multi platform application development framework created by Google. It was first released in 2017 and ability to help developers build high-performance, cross-platform apps for iOS, Android, the web and, desktop. Flutter uses a reactive programming model, which means that it can build user interfaces that automatically update themselves in response to changes in the app's state. Flutter also offers a rich set of pre-built widgets and tools that make it easier to create beautiful, responsive, and interactive UIs. Overall, Flutter is a powerful tool for building high-quality mobile apps that work seamlessly across different platforms, and it has become a popular choice for developers looking to create modern, responsive, and engaging user experiences. #### Blazor Blazor is a free and open-source web application development framework developed by Microsoft. It allows developers to build interactive and dynamic web applications using C# and HTML instead of traditional web technologies like JavaScript. One of the key advantages of Blazor is that it allows developers to leverage their existing skills and tools, such as C# and Visual Studio, to build modern web applications. It also offers a component-based architecture and a rich set of pre-built UI components, making it easier to create complex and responsive web UIs. Overall, Blazor is a powerful and flexible framework that can be used to build modern web applications using C# and HTML, and it has become a popular choice for developers looking to create rich and interactive web experiences. ## 5 - Delivery Plan ### 5.1 Timeline #### 5.1.1 Mobile And Web Internet Banking ```plantuml @startgantt <style> ganttDiagram { task { FontName Helvetica FontColor blue FontSize 18 FontStyle bold BackGroundColor GreenYellow LineColor blue } </style> printscale weekly Project starts the 1st of July 2023 [UI & UX Design] lasts 8 weeks then [Component Design] lasts 4 weeks [Mobile Development] lasts 36 weeks [Mobile Development] starts at [Component Design]s end [Web Development] lasts 36 weeks [Web Development] starts at [Component Design]s end [IDM Integrations] lasts 24 weeks then [SSO Portal] lasts 8 weeks @endgantt ``` #### 5.1.2 Loan, CRE And Insurance Workflows ```plantuml @startgantt <style> ganttDiagram { task { FontName Helvetica FontColor blue FontSize 18 FontStyle bold BackGroundColor GreenYellow LineColor blue } </style> printscale weekly Project starts the 1st of July 2023 [Consumer Loan Workflow] lasts 36 weeks [Auto Loan] lasts 4 weeks [Auto Loan] starts at [Consumer Loan Workflow]s end [Housing Loan] lasts 4 weeks [Housing Loan] starts at [Consumer Loan Workflow]s end [Buyout Loan] lasts 4 weeks [Buyout Loan] starts at [Housing Loan]s end [Term Deposit] lasts 4 weeks [Term Deposit] starts at [Housing Loan]s end [Loan with CC] lasts 4 weeks [Loan with CC] starts at [Term Deposit]s end [TopUp Loan] lasts 4 weeks [TopUp Loan] starts at [Term Deposit]s end [CRE Workflows] lasts 16 weeks [CRE Workflows] starts at [Consumer Loan Workflow]s end [Credit Card] lasts 16 weeks [Credit Card] starts at [Consumer Loan Workflow]s end [Insurance Workflows] lasts 16 weeks [Insurance Workflows] starts at [Consumer Loan Workflow]s end @endgantt ``` ### 5.2 Project Team #### 5.2.1 Mobile And Web Internet Banking | Resource | FTE | | ---------------- | ------ | | Architect | 3 | | Senior Developer | 10 | | Analyst | 3 | | UI/UX | 3 | | Tester | 2 | | Manager | 2 | | **Total** | **23** | #### 5.2.2 Loan, CRE And Insurance Workflows | Resource | FTE | | ---------------- | ------ | | Architect | 3 | | Senior Developer | 6 | | Analyst | 2 | | Tester | 2 | | Manager | 1 | | **Total** | **14** | ## 6 - Governance ### 6.1 Risk Management A risk management plan will be included with the detailed plan. Main aspects of the risk management plan will be: * how to identify potential risks and challenges that may be encountered during the project * how to determine risk categories and risk values * how to identify the mitigation strategies and solution plans to address these risks * how to monitor risk life cycle With the beginning of the project, the Project Management Team and Project’s Steering Committee will be defined. The Project Management Team will prepare the risk management plan and will communicate risk management life cycle with project team and all the stakeholders. Within the project’s life cycle, the risk life cycle will be as below: * a risk can be identified by any team member or stakeholder * the risk will be recorded * the risk category, risk value, risk owner will be defined * the risk owner will determine the mitigation strategy and solution plan for the risk and inform the related parties * the risk will be monitored and reported through out it’s life cycle * the open risks will be reported to the Steering Committee and for the ones that can not be managed by the project team will be escalated for solution and guidance. #### 6.2 Change Management A change management process will be established, outlining the procedures for requesting, reviewing, and implementing changes to the project scope, deliverables, or timeline. This process will ensure: * how to define a change request * how to determine the effect of the change in time, scope and budget * any changes are properly documented and approved by both parties. With the beginning of the project, the Project Management Team and Project’s Steering Committee will be defined. The Project Management Team will prepare the change management plan and will communicate change management life cycle with project team and all the stakeholders. Within the project’s life cycle, the change life cycle will be as below: * a change can be identified by business or project team * when it occurs it should be recorded for impact analysis * as soon as the details for impact analysis is provided, the related team members will make a high level impact analysis for timeline, cost and scope of the project and prepare an impact analysis report. This report will also include the alternatives to manage the change request ( postpone, forego, partially manage etc) * The impact analysis will be reported to the steering committee and according to the committee’s decision the related updates will be done and published regarding project outcomes. ### 6.3 Acceptance Criteria The acceptance criteria for the project will be defined, specifying the conditions that must be met for the project to be considered complete and successful. These criteria will serve as a benchmark for evaluating the project's performance and determining whether the deliverables meet the client's expectations. ### 6.4 Support A plan for post-implementation support will be detailed, outlining the services and resources that will be available to the client after the project has been completed. This may include ongoing maintenance, technical support, and any necessary updates or upgrades. By incorporating a related work order into the digital banking system proposal, we ensure that all aspects of the project are clearly defined, and both parties have a clear understanding of the expectations, responsibilities, and deliverables. This structured approach will help facilitate a smooth implementation process and contribute to the overall success of the digital banking system. ## 7 - Assumptioms ### 7.1 Introduction The success of any project largely depends on the clarity and mutual understanding of all involved parties. The Assumptions section aims to outline the basic presuppositions that BTech holds while proposing the software delivery plan. These assumptions help us define the project scope and estimate the required resources and effort, forming the baseline of our collaboration. These assumptions cover various aspects of the project, including design, analysis, API requirements, environment setup, quality assurance, hosting, commercial terms, technical specifications, project management practices, intellectual property rights, and general considerations. It is crucial to note that these assumptions are built upon standard practices and prior experiences, and any deviations or changes to these assumptions might impact the project's timeline, resources, cost, or scope. Hence, we request you to review these assumptions carefully and bring up any discrepancies or clarifications at the earliest possible stage. The assumptions will be revised and agreed upon as part of the project kickoff, ensuring that we have a common understanding before we embark on this journey together ### 7.2 Design Assumptions We anticipate two rounds of revisions for each design deliverable, not exceeding two person-days of effort per revision. Should the volume or effort of revisions surpass these limits, we reserve the right to adjust the project plan and seek additional funding. We will consider each design deliverable signed-off if we do not receive feedback or sign-off from the customer within three workdays post-delivery. ### 7.3 Analysis Assumptions We accommodate two rounds of revisions for each analysis deliverable, each not exceeding two person-days of effort. If revisions exceed these constraints, we may revise the project plan and seek an additional budget. If we don't receive feedback or sign-off from the customer within two workdays post-delivery, the analysis deliverable is deemed approved. ### 7.4 Architecture and API Requirements Assumptions We expect the customer to provide API specification documents, API-feature mapping documents, and sample request/response definitions in an orderly format. We are not accountable for the performance and limitations of third-party APIs. We are not liable for the performance, content, or failure of third-party Web Views/iFrames due to complex or unsupported JavaScript or HTML functionality. We anticipate timely communication from the customer regarding infrastructural or environmental changes affecting applications we develop. We may reassess the plan and budget accordingly. The customer is responsible for setting up UAT/Pilot and Production environments. ### 7.5 Development Environment Assumptions We assume 24/7 availability of the customer-maintained development and test environments unless otherwise specified. We expect a minimum two-day advance notice from the customer regarding any infrastructural changes impacting our development services or project environments. ### 7.6 Quality Assurance Assumptions We expect the customer to provide all requested test data on time, formatted as per given specifications, and reflecting real user and/or transaction data. The customer is responsible for thorough testing during the UAT period, and logging all issues into the project under our Azure Devops account. ### 7.7 Commercial Assumptions Out of scope items and change requests are billed as per the rates in the Rate Card. Scope reduction during project delivery may incur additional costs. Change requests to the scope will alter the total project budget and influence the maintenance fee. ### 7.8 Technical Assumptions Third-party SDK integrations are outside the scope and will be analyzed at project kickoff. All SDKs for End User Applications should be compatible with Native Development Kits, and Reader Applications should be compatible with Flutter. We bear no responsibility for non-compatibility issues. ### 7.8 Project Management Assumptions To maintain effective content updates, we will use tools like Azure Devops to document user flows and analysis, accessible to the client. We expect the customer to provide all necessary documents, Apis, and feedback in a timely manner to avoid delays and additional costs. ### 7.9 Hardware,Software & Realted Vendors Support Assumptions Hardware for testing and production environments: The procurement and setup of physical or virtual hardware, including servers and storage systems, required for both testing and production stages of the project. Software components and monitoring tools: The costs and management of operating systems, Kubernetes (for container orchestration), database licenses, and application performance monitoring tools are not part of this proposal. The client will be responsible for acquiring and maintaining these components. Official vendor support for Apisix Gateway and Zeebe workflow engine: While our solution incorporates the Apisix Gateway (API gateway) and Zeebe (workflow engine), we do not offer official support services from the respective vendors. Should the client require assistance from the creators of these technologies, they will need to secure these services separately. ### 7.9 General Assumptions We do not assume responsibility for content creation and management. By highlighting these exclusions, we aim to provide clarity on the services that fall outside the scope of our proposal. The client should take these exclusions into account when planning the project to ensure a successful outcome ## 8 - Intellectual Property Terms This section outlines the agreement between BurganTech and the customer regarding the Intellectual Property (IP) rights for this project. ### 8.1 Original Software The Intellectual Property rights of the original software, including the source code, documentation, and related material, remain the exclusive property of BurganTech. Any access granted to the original software, including full access to the source code, is solely for the execution and modification of the software within the scope of this project. This access allows the customer to modify the original software for their own use, but does not imply transfer of ownership, or the right to distribute, sell, or sublicense the original software. Original software includes * Banking & IDM Gateway * Workflow Management * Contract & Document Verification System * Transaction Management ### 8.2 Customizations The customizations, modifications, or enhancements made to the original software, tailored specifically to meet the customer's requirements for this project, will be the sole Intellectual Property of the customer. This includes any newly written code, configuration changes, and all other alterations made to adapt the software to the customer's specifications. The customer holds exclusive ownership rights to these customizations. ### 8.3 Third-Party Components Please note, these terms do not include any rights to third-party components or software utilized within the project, which will be governed by their respective licenses. The customer must own all font licenses and stock images. It's critical that these IP terms are thoroughly reviewed and agreed upon to avoid any future misunderstandings or disputes. If there are any questions or if any aspect of the IP terms is unclear, we encourage you to bring it up so we can address it promptly. ## 9 - Financial Terms ### 9.1 Introduction #### Purpose of the financial terms section This section of the software delivery proposal outlines the various financial aspects of our collaboration. It aims to provide transparency in the pricing model, cost breakdown, payment terms, and other related financial factors. Our goal is to ensure that all parties have a clear understanding of the financial commitments and expectations involved in the successful delivery of the software project. #### Scope of the financial terms The financial terms covered in this section include the following key areas: * Pricing model: The structure under which pricing for the project is determined, and factors influencing its selection. * Cost breakdown: A detailed analysis of the costs involved in software development, implementation, and maintenance. * Payment terms: The agreed-upon schedule and methods for making payments, including invoicing, billing, and late payment policies. * Additional fees and expenses: Information about any other fees or expenses not included in the main cost breakdown, such as taxes, travel, and third-party services. * Financial risks and contingencies: Identification of potential financial risks, their mitigation strategies, and contingency plans for unforeseen circumstances. * Termination and refund policy: Details on the conditions under which the project may be terminated and refunds issued, if applicable. By providing a comprehensive overview of the financial aspects of the project, we aim to create a strong foundation for a mutually beneficial partnership and to address any questions or concerns related to project costs and payment arrangements. ### 9.2 Pricing Model As a dedicated partner for the group companies, our primary aim is to deliver high-quality software solutions that meet your specific needs. While we need to cover our costs, our focus is not on profit, but on fostering a successful, long-term relationship with you. We utilize a Cost-Plus pricing model, targeting an average rate of $400 per man-day. We guarantee that this rate will not be exceeded, ensuring a predictable cost structure. The total man-days spent on the project will not exceed the initial estimate of 6250 man-days, as long as the project scope remains consistent. Although changes to project assumptions may sometimes impact the timeline and costs, they do not necessarily always result in extra costs. Every situation will be evaluated individually, ensuring we maintain our commitment to transparency and value. ### 9.3 Payment Terms This section outlines the payment terms for our project, based on the man-days spent monthly. #### 9.3.1 Down Payment A down payment of 10% of the total project cost is required to commence the project. This amount will be invoiced upon contract signing and must be paid before work begins. This down payment will be deducted from the final invoice at the conclusion of the project. #### 9.3.2 Billing Cycle BurganTech operates on a monthly billing cycle. At the end of each month, the customer will receive an invoice reflecting the total number of man-days spent on the project during that month. The invoice will itemize the work performed, including the number of man-days dedicated to each task or deliverable, and the associated costs. #### 9.3.3 Payment Due Date Upon receipt of the invoice, payment is due within 30 days. #### 9.3.4 Method of Payment Payments can be made via wire transfer, check, or any other pre-agreed method. The invoice will include detailed information on how to make the payment. #### 9.3.5 Disputes In the event of a dispute regarding an invoice, the customer should contact BurganTech within 10 business days of receiving the invoice. If no dispute is raised within this period, the invoice will be considered accepted. Please note that the customer's commitment to timely payments is crucial for the smooth progression of the project. Delays in payments can lead to delays in project delivery. By agreeing to these payment terms, the customer acknowledges their responsibility to pay for the man-days spent on the project as billed monthly by BurganTech. ### 9.4 Additional Fees and Expenses In addition to the costs outlined in our proposal, there may be certain additional fees and expenses that will be borne by the customer. These include: #### Travel Expenses Should our team members need to travel to the customer's location for meetings, training, implementation or any other project-related activities, the associated travel costs will be charged to the customer. These costs may include: - **Airfare**: The cost of round-trip air travel to the customer's location. - **Lodging**: Accommodation costs for the duration of the stay. - **Meals and Incidentals**: Per diem costs for meals and incidental expenses. - **Ground Transportation**: Costs for car rental, taxis, public transportation or mileage reimbursement for use of personal vehicles. - **Other Travel-Related Expenses**: Any other necessary expenses directly related to the travel, such as travel insurance, visa fees, etc. #### Miscellaneous Expenses There may be other miscellaneous expenses not outlined in our proposal but incurred in the course of the project. These could include special equipment, software or licenses needed specifically for this project, or additional services required to meet the project goals. All these expenses, when incurred, will be billed at actuals. Detailed receipts will be provided to ensure transparency. For major expenses, we will seek the customer's approval before making the expenditure. Note that all additional fees and expenses will be invoiced separately from the project costs outlined in our proposal and will be subject to the payment terms outlined in the contract. ### 9.5 Financial Risks and Contingencies Project execution often carries inherent financial risks that are important to recognize and manage effectively. Here, we outline the primary financial risks associated with this project and our mitigation strategies: Project Scope Change: Unanticipated expansion of the project scope can lead to increased costs. We aim to mitigate this risk through clear communication, detailed project planning, and a robust change control process. Any scope changes will be discussed, documented, and agreed upon before proceeding, ensuring full transparency on potential cost implications. Timeline Extensions: Delays in project execution, whether due to changes in project assumptions or unforeseen circumstances, may result in increased costs. We maintain a proactive approach to project management and schedule buffer allocation to account for potential delays. However, not all changes to project assumptions will necessarily result in extra costs. Exchange Rate Fluctuations: For international projects, fluctuations in exchange rates can have a significant impact on the project's overall cost. Our invoices are issued in the agreed-upon currency to mitigate this risk. ## 9.6 Termination and Refund Policy Termination: Either party may choose to terminate the agreement with written notice. The length of the notice period, often 30 days, will be agreed upon during the contract negotiations. Customer Initiated Termination: If the customer chooses to terminate the project prematurely, the customer will be responsible for paying for all services provided up until the termination date, including any work in progress. Vendor Initiated Termination: If we, as the vendor, choose to terminate the agreement, the customer will only be responsible for the services rendered until the termination date. Refunds: Any down payment made is non-refundable except in situations where the vendor is unable to deliver the agreed-upon services. If a customer terminates the agreement, they will not be entitled to a refund of any payments made prior to termination, but they will not be billed for any services not yet provided. In the event of vendor-initiated termination, the customer will be refunded for any prepaid services not yet provided. Project Assets: Upon termination, all project assets and completed work up to the point of termination will be handed over to the customer. If the project is not fully completed, the customer will receive all work completed up to the termination date. This termination and refund policy aims to protect both parties involved in the agreement and ensures fair treatment in the event of termination.