Erik Bogaerts, CEO, commented: “Germany is a key market for Naqoda and our German Flat Withholding Tax Engine. We’ve always believed that proximity to our customers and partners is key in continuing to build our market presence in Germany.”

The new launch follows a year of active and successful prospecting in the German market.

For a complete version history please click here.

== 1.2.0 (November 2012) ==
* Added new calculation method (684221)
* New option to cancel operations via the import corrections batch interface (440780)
* New option to upload backdated FSA compatible with new calculation mode in import corrections batch (440780)
* Fixed issue with reset FSA process
* Changed ordering of transactions to present customer records before transaction records
* Updated framework to version 1.4.5
* Added year selector in engine screen
* Added totals used and available in engine screen
* New report to list FSA (549329)
* Removed obsolete templates directory
* Removed obsolete logs directory

== v1.1.5 (June 2012) ==
* Added new clients current FSA report
* Updated jQuery library to version 1.7.2
* Moved client forms to framework
* Changed distribution amount fields to new format
* Added possibility to log received web service calls
* Added new transaction import function
* Added new directories fwktec/fields, fwktec/includes,fwkusr/includes

== v1.1.4 (May 2012) ==
* Added new report ‘Clients current FSA’
* Added new report ‘Clients latest set FSA’
* Updated framework to version 1.3.1

== v1.1.3 (February 2012) ==
* Deduct customer type from group type instead of from individual client in case of group clients
* Distribute assets usage equally over clients if usage doesn’t total 100%
* Made percentage usage mandatory in add client and update client web services
* Updated framework to version 1.3.0

== v1.1.2 (January 2012) ==
* Added new ‘FSA Reset’ process
* Added new ‘FSA Reset Corrections’ report
* Upgraded framework to version 1.2.3
* Fixed issue with the ClientUpdate web service where in some cases the historic client record retrieved wasn’t the most recent one

Finding the best way to tackle legacy core systems has re-emerged as a key topic of debate among banks, from top tier global players to smaller, domestic institutions. With their vast, fragmented architectures, banks’ legacy systems are typically cumbersome and lack the agility required to adapt to today’s business and market needs. Factors such as evolving customer expectations, new regulations and the need to enter new geographies or launch new products require banks to have flexible systems that can continually adapt to support their evolving business needs.

With legacy systems so far having failed to address these changing requirements, banks should consider four crucial aspects to make their core banking systems more efficient this year: componentisation, going back to the core, compliance and customer centricity.

So let’s continue with the final C: customer centricity.

As the industry emerges from the economic crisis, many banks are aware of the fact that there is a need to re-establish trust and customer confidence in their services. Following the risk-friendly and somewhat greedy years of the 2000s, customers now need to be put back at the heart of a bank’s strategy to ensure they remain competitive in an ever more crowded market place.

As banks look to refresh their overall core banking infrastructure, they must also look to store information at every level of detail in relation to all customer activities across the bank and then link this back to the account portfolio to gain a single customer view. What’s more, the multiplication of channels, such as mobile or social media platforms, is making matters even more complex and a comprehensive and cross-channel customer view is therefore becoming increasingly important.

An outdated or fragmented core system prevents banks from achieving a single view of each customer portfolio, creating an obstacle for the front office to manage their customers and maximise revenues. In addition, the banks are then faced with a high cost of ownership and high risk due to inconsistencies across the IT infrastructure due to an accumulation of multiple systems. As such, banks must be fully equipped with the appropriate information to be able to manage and up-sell across multiple channels.

To conclude, a lot seems to be changing in 2011 in the banking space with new payment channels, such as mobile, gaining in popularity the implementation of SEPA finally becoming a reality. In order for banks to deal with these changes and many more, a flexible and modular banking system will be the key to financial institutions coping with the challenges before them and capitalising on the business opportunities that also exist.

If you missed the earlier parts, you can find them here: componentisation, going back to the core and compliance .

== v1.1.1 (December 2011) ==
* Upgraded framework to version 1.2.2
* Auto reset FSA values over year change
* Fixed issue with search client not working if company field set to NULL
* The PositionsGet web service now returns zero values instead of null values when no used amounts are found
* Fixed issue with loading jQuery date picker script

== v1.1.0 (1 August 2011) ==
* Extended SOAP interface PositionsGet to retrieve FSA positions and usage on previous years
* Fixed issue in TxnAdd SOAP interface where values were being returned for last calculated record instead of current record (531084)
* Added upload of dump files functionality

== v1.0.8 (18 June 2011) ==
* Added new options to handle FSA, in function of chosen business process

== v1.0.7 (June 2011) ==
* Added export to CSV file for reports

== v1.0.6 (May 2011) ==
* Fixed rounding issue in return value of Reconcile web service (299216)
* Added FSA validity date to ClientAdd and ClientUpdate web service (366887)
* Added used FSA and other buckets to GetPositions web service (998348)
* Fixed issue with FSA set to zero during client update not registering the zero value but keeping the old FSA value (285420)

== v1.0.5 (May 2011) ==
* Fixed issue with FSA reset to zero not updating correctly
* Set church tax to 0% in case the Bundesland is not known
* Added shortcut to create new user roles

== v1.0.4 (May 2011) ==
* Changed Reconcile web service, ReconcileRequest field “type” from float to string
* Fixed issue with client update button not working via online web interface
* Added tests on existence of historical client record in case of a client update
* Changed sort in client overview so that the latest record is always shown first
* Fixed issue with empty death date and birth date in client creation and update (453505)
* Fixed formatting issue of death date and birth date in case of empty values (745772)
* Fixed issue with church tax set to ‘no church tax’ not interpreted correctly in case of a change of customer attributes (918488)
* Fixed issue with tax indicator set to ‘not subject to tax’ not interpreted correctly in case of a change of customer attributes

== v1.0.3 (8 May 2011) ==
* Improved performance of calculations
* Added new correction web service
* Added new reconciliation web service
* Broke down ClientAdd web service into ClientAdd for new client creation and ClientUpdate for update of client tax attributes
* Removed option for temporary transaction cancellation
* Added check to see if database configuration file exists before continuing and avoiding system error message
* Updated packaging not to include /config contents in release zip file
* Changed deployment method for default database configuration file
* Fixed warning “Declaration of submitZfSubElement::verifyall() should be compatible with that of zfSubElement::verifyall()”
* Redirect user to engine page after selecting a customer
* Don’t show engine menu if no access
* Added locking of customer when processing transaction to manage concurrent processing on same customer
* Added access control on web service calls

== v1.0.2 (10 April 2011) ==
* Don’t show “Add column” if development framework not installed
* Some lists not aligned properly on screen
* Changed the way dump query function works
* Moved template scripts to template folder
* Fixed issue with redirects not working
* New web service to Show used FSA and other exemption buckets
* Implement export scenario function

== v1.0.1 (23 January 2011) ==
* Adjusted directory structure
* Don’t allow deletion of own user
* Added user password reset option for administrator
* Changed table views to extend over whole width of screen
* Strengthened user security
* Moved sessions storage from file to DB
* Renamed Administration menu to Setup menu

Finding the best way to tackle legacy core systems has re-emerged as a key topic of debate among banks, from top tier global players to smaller, domestic institutions. With their vast, fragmented architectures, banks’ legacy systems are typically cumbersome and lack the agility required to adapt to today’s business and market needs. Factors such as evolving customer expectations, new regulations and the need to enter new geographies or launch new products require banks to have flexible systems that can continually adapt to support their evolving business needs.

With legacy systems so far having failed to address these changing requirements, banks should consider four crucial aspects to make their core banking systems more efficient this year: componentisation, going back to the core, compliance and customer centricity.

So let’s continue with the third C: compliance.

In addition to increased competition in the banking space and a need for cost reduction, it is regulatory initiatives such as the Single Euro Payments Area (SEPA), the Payment Services Directive (PSD), the latest Basel III proposals and the UK’s Faster Payments Service (FPS), to name just a few, that are driving banks to refocus on their core banking infrastructures. Banks need flexible solutions in order to comply and respond to the evolving legislative requirements.

As part of some of the regulatory changes, the ISO 20022 messaging standard, for example, has emerged as the recommended format for all payment processing steps under SEPA. It introduces a number of benefits, such as greater STP rates that enable banks to save time and money. What’s more, it offers a more standardised payments service that allows banks to conduct business across national borders, thereby delivering improved customer service. Crucially, ISO 20022 will streamline and standardise payment processes, which means that banks will also have a greater opportunity, as well as more time and money, to focus on innovating payment solutions and services.

In order to take advantage of the benefits new regulatory initiatives offer, the move from old, siloed legacy systems to a universal messaging standard will help both banks and their corporate customers to enhance their transaction processes and help them reduce the global maintenance costs dedicated to payments processing.

Finding the best way to tackle legacy core systems has re-emerged as a key topic of debate among banks, from top tier global players to smaller, domestic institutions. With their vast, fragmented architectures, banks’ legacy systems are typically cumbersome and lack the agility required to adapt to today’s business and market needs. Factors such as evolving customer expectations, new regulations and the need to enter new geographies or launch new products require banks to have flexible systems that can continually adapt to support their evolving business needs.

With legacy systems so far having failed to address these changing requirements, banks should consider four crucial aspects to make their core banking systems more efficient this year: componentisation, going back to the core, compliance and customer centricity.

So let’s continue with the second C: going back to the core.

If traditional banks want to be in a position to react to increasing competition in the banking market, an agile and modular core banking system will give them the necessary degree of independence, both on the business and on the IT level, to quickly expand their business, deliver more profitable products, enter new markets and ultimately attract additional lines of revenue. At the same time, banks will be able to focus on their key strengths while at the same achieving cost efficiencies.

In fact, a recent report by Ovum, ‘A Change for Good in Core Banking Systems’, suggests that banks’ core systems will assume greater prominence from 2010 as financial institutions continue to adjust to an altered competitive landscape and a revised set of priorities. With the renewed focus on core banking systems, a piece of Callataÿ & Wouters European market research conducted in 2010 backs these findings and shows that banks are keen to refresh their outdated systems. According to the findings, 66 per cent of respondents across the UK, Germany and France agreed that the events of the past two years in the finance industry have increased the importance of core banking systems to the business.

It looks like 2011 will be the year when a significant proportion of banks increase their investment in their core banking systems with 44 per cent of research respondents planning to increase spend on their systems over the next two years in order to enhance competitiveness, meet regulatory initiatives and manage risk.

With cost and competition being prime drivers for an infrastructure refresh, banks need to start ridding themselves of the burden of inflexible solutions which were typically designed and implemented when the financial world was a very different place.

With legacy systems so far having failed to address these changing requirements, I’ll discuss why banks should consider four crucial aspects to make their core banking systems more efficient this year: componentisation, going back to the core, compliance and customer centricity.

So let’s start with the first of the 4 C’s of core banking: componentisation.

Forrester’s research entitled ‘The Future Shape Of Banking Architecture In 2023’ , identifies a series of requirements as well as the architectural layers of the future banking platform. The key layers focus on personalised customer services and real-time information analysis; a separation of product design and customisation; and a clear distinction between core competencies and non-differentiation functions supported by selective sourcing.

In practice, this means that the big banks are focusing on what they are good at and outsource the rest, whereas new entrants are typically focusing on specific areas within the financial services value chain, such as loans, selling the products of other big players. This approach is already enabling, MoneYou in The Netherlands, for example, to sell loans managed by Fortis. Meanwhile Tesco in the UK, Carrefour in France and Volkswagen in Germany have all entered the financial services market offering payment services from traditional financial institutions in addition to their core offering.

With the traditional banking value chain breaking up, increasing competition in the space and the need to drive down costs, traditional banks, as well as new entrants, will require the flexibility to operate agile banking models that can adapt easily to changes in regulation and market and customer demands. As such, banks and corporates wishing to operate in this market need to ensure their infrastructure is based on a flexible and scalable Service Oriented Architecture (SOA) that enables them to easily and quickly roll out additional products, services and channels to respond to evolving market demands.

The 2nd C will follow next week, so watch this space …