miércoles, 27 de febrero de 2013

Gestión de hipotecas en SAP

Por Norbert Nielsen - Manging Partner en ConVista Consulting

El módulo de SAP CML (Corporate Mortgage Loans) cuenta con funciones de gestión de garantías complejas, ayuda para la toma de decisiones y una serie de opciones para ultimar los contratos. Además de la gestión de créditos hipotecarios, el módulo SAP CML posibilita la gestión de préstamos, tales como préstamos de consumo, a empleados, a empresas asociadas, sobre pagaré etc.
 
En el siguiente gráfico se puede ver el flujo de una hipoteca y sus funciones en SAP CML, desde una solicitud hasta un contrato y las funcionalidades que se admiten en la gestión de los interlocutores, las condiciones y los datos maestros de un préstamo.
 
SAP CML

De acuerdo a las necesidades de la empresa, las operaciones de préstamo se pueden subdividir en clases de producto, que se pueden utilizar para definir clases de préstamo o divisiones específicas. Se pueden observar a su vez las contabilizaciones que se generan en SAP CML y su traspaso a FI para su cobro con el programa de pagos automático.
 
La gestión de préstamos está completamente integrada en la Tesorería de SAP, lo que permite medir de forma directa los efectos que tienen las operaciones de préstamo en la liquidez, el riesgo, las posiciones y movimientos.
 
La gestión central de intermediarios financieros facilita la entrada de datos como dirección, datos personales, datos de pago, cuentas de contabilidad, relaciones con otros interlocutores, datos de solvencia y datos fiscales entre otros muchos registros.
 
SAP CML

Los datos maestros del préstamo son la base de las condiciones del contrato. La amortización, los intereses y los gastos se utilizan para generar registros planificados, necesarios para el tratamiento posterior de los acreedores y deudores. También se pueden definir paneles de nuevas operaciones para definir sus condiciones generales para préstamos activos.
 
Además se introducen como datos básicos la clasificación y agrupación de cada préstamo, los importes del contrato y las reglas de contabilización, donde se especifica el método que se debe utilizar para las periodificaciones de descuento.
 
Una vez que se ha calculado la solvencia, asignado las garantías y los objetos y hallado el valor de pignoración donde sea conveniente en la gestión de objetos, se puede añadir más información antes de concluir el contrato. El contrato se puede pagar en un solo pago o en varios pagos parciales.
 
Dentro de las funcionalidades de CML destacamos:



  • Prórroga: A través de esta función se ajustan automáticamente las condiciones del préstamo al final del período.
  • Gestión de Objetos y colaterales para hipotecas
  • Transferencia de capital: Permite crear un sólo contrato a partir de varios o a la inversa.
  • Contabilización de registros: Permite la contabilización automática de todos los registros planificados de uno o varios préstamos.
  • Creación de pagos: A través del programa de pagos automático se procesan las operaciones de pago para préstamos, gestionadas sobre la base de las cuentas de deudor.
  • Tratamiento posterior de pagos: Los pagos que no se pudieron asignar y que por lo tanto se han contabilizado en la cuenta de deudor como un pago adelantado o un pago en exceso o se han contabilizado en la cuenta de rechazos se pueden tratar a través de esta función.
  • Periodificación: Utilizando el procedimiento de anulación o de diferencia, se puede ejecutar la periodificación tanto de los intereses como de los gastos.
  • Anulaciones: Con esta función se pueden anular posiciones del debe, entradas de pago, pagos, traslados de capital y otras contabilizaciones.
  • Traspaso de posiciones: Cuando se modifica una referencia de imputación, el traslado de la cuenta de balances se realiza con la función traspaso de posiciones.
 
Integración y adaptación de CML a la empresa
El módulo de SAP CML está totalmente integrado en SAP  y cuenta con interfaces a FI (Finanzas), CO (Controlling), AA (activos Fijos), Real Estate (Gestión de Bienes Inmuebles ), etc.

SAP facilita mucho el manejo con la aplicación y aumenta la flexibilidad de los usuarios a través de un “Easy-to-use-Front-End” con el producto de Microsoft Excel y Business Objects. Además cuenta con la posibilidad de cargar datos de aplicaciones como Reuters o Bloomberg en nuestro sistema.
 
SAP CML

En una implantación de SAP CML la empresa ha de enfrentarse a varios retos. No sólo hay que tener en cuenta las restricciones normales como el tiempo, los Recursos Humanos y el presupuesto, sino también las tareas durante la parametrización del sistema y su adaptación a los procesos de negocio de una empresa. Además hay que contar con los posibles ajustes del Management Reporting, de la correspondencia externa, de las interfaces a otras aplicaciones, la migración y la configuración técnica.
 
SAP CML




miércoles, 20 de febrero de 2013

La cuenta atrás para SEPA

Por José Martínez - Consultor en ConVista Spain

SEPA es una realidad que tendrá su puesta de largo el próximo 1 de Febrero del 2014. Las empresas que a día de hoy ni siquiera se hayan planteado comprar el vestido que deberán lucir ese día quedarán fuera del baile.
Durante los últimos años cabía la posibilidad de plantear la migración a SEPA de modo reflexivo, suponía una oportunidad estratégica para analizar el mapa bancario de cada compañía con el objetivo de racionalizarlo. Aunque todavía no es descartable esta reflexión, los plazos se han acortado y a día de hoy esta adaptación regulatoria debe afrontarse sin más dilación, convirtiendo el carácter estratégico de este proyecto en meramente regulatorio.
No obstante el carácter regulatorio, no debe llevarnos al engaño de que solo compete al departamento de sistemas, SEPA no se trata de una mera conversión de formatos. Afecta a todos los departamentos de una compañía, desde el departamento comercial con la gestión de terceros y “mandatos” hasta el departamento de tesorería, con la posibilidad de centralizar pagos.
 
SEPA

Además, esta regulación supone una serie de oportunidades para todas las compañías, cierto es, que éstas son mayores conforme mayor sea la diversificación geográfica y operativa de las mismas.
  • Acortamiento de los plazos de pago y reducción de los costes asociados a los mismos.
  • Ayuda para la conquista de nuevos mercados (marco regulador común reduciendo barreras fiscales y burocráticas en cada país)
  • Homogeneización de precios y de comisiones bancarias (no es una utopía, es una realidad demostrada en países como Francia y Finlandia)

 
Algunas de estas oportunidades se encuadran dentro del nuevo escenario que ofrecen las metodologías de pago SEPA:

1. Transferencias SCT y sus puntos clave:
  • Formato XML: Este formato es vinculante para el intercambio de todas las operaciones de SEPA entre bancos. Sin embargo, los bancos pueden seguir aceptando otros formatos de clientes para la instrucción de los pagos de SEPA bajo ciertas condiciones.
  • Los identificadores únicos permitidos para las transacciones de la cuenta de SEPA son el número internacional de cuenta bancaria (IBAN) y el Banco Código de identificación (BIC). Hasta ahora, la mayoría de los países han utilizado estos identificadores para los pagos transfronterizos.
  • El cambio obligatorio a la información de remesas. En virtud de SEPA, la longitud estándar de esta información es de 140 caracteres, y los bancos están obligados a proporcionar la información en su totalidad en los estados de cuenta.
  • El plazo máximo de ejecución de las transferencias SEPA en un día hábil.
  • Las transferencias SEPA se acreditan en su totalidad sin deducción de los honorarios de la cantidad principal.
  • Extractos electrónicos MT940 o CAMT (el “XML” del MT9040) basados en el mismo lenguaje y estructura que garantizan una conciliación bancaria automática casi perfecta.
2. Adeudos Directos SDD: Esquema Core VS B2B
  • En un proceso de gestión de cobros entre empresas, las partes involucradas tendrán la libertad  de ponerse de acuerdo para utilizar el esquema Core  o el B2B.
  • No es posible utilizar el esquema de B2B en relación con los consumidores o particulares, por razones de protección a los mismos.
  • La diferencia fundamental entre los dos sistemas radica en la finalidad de los pagos. El adeudo directo Core puede ser devuelto por el deudor hasta 8 semanas después de haberse ejecutado el mismo, mientras que el adeudo con arreglo al régimen B2B no es reembolsable por el deudor (en la misma firma del contrato se adhiere a un cláusula de no devolución)
  • Una diferencia fundamental consiste en que la participación en el esquema Core es obligatoria para los bancos de la zona euro, mientras que el B2B es opcional, aunque se prevé que la mayoría de los bancos también ofrezcan el servicio de gestión del B2B.

 
La siguiente pregunta que está en el aire es: SEPA ¿Estamos preparados? Spain is different en todos los sentidos y en lo que respecta a la migración a SEPA no íbamos a cambiar. Nuestro país se ha acogido a las disposiciones transitorias que se demorarán hasta Febrero del 2016 (periodo de transición). Esto se traduce en las siguientes pautas de actuación:
  • Durante estos dos años de transición las compañías podrán continuar realizando sus comunicaciones bancarias de transferencias y adeudos en formato txt. Materializadas a través del cuaderno 34.14 y 19.14 (44 dependiendo del esquema core o b2b).
  • Durante el mismo las compañías podrán continuar enviado el código C.C.C propio y del cliente en los campos habilitados a tal fin en los ficheros de remesas. Las entidades bancarias ofrecerán el servicio de conversión al IBAN
  • Exención de algunos productos nicho como son los anticipos de créditos que se materializarán en los entidades bancarias a adeudos directos.
Más allá del 2014 habrá nuevos retos por afrontar dentro del marco SEPA. No todo termina con la migración, se continuará innovando en la gestión de los pagos por móvil, Smartphone, soluciones específicas de pago para el comercio electrónico (e-payments) y la facturación electrónica.


jueves, 14 de febrero de 2013

The black box called SAP Bank Analyzer?

by Logan Skibbe – Senior Consultant at ConVista Spain

During the last years the term SAP for Banking has been heard frequently, but hardly perceived when talking about Bank specific applications. However, for more than a year now, it seems that SAP this time really breaks into the Banking Market.

SAP offers a wide and sophisticated range of products to meet the specific needs of the Banking Industry.
It’s quite easy to get lost in this solution jungle and the common practice of SAP to name and rename their products does not really help. In one tech blog someone even raised the question if the Bank Analyzer “is just too complex to work with”. It is correct that it has dozens of different functionalities and at first sight you might feel swamped, but after a closer look you will see what a powerful and mature tool SAP has created.
Let’s get started with the big picture and then break down and focus on the Bank Analyzer. With Banking Services SAP provides an industry solution that offers a variety of applications covering the whole value chain.
I think most confusion starts with the fact that certain functionalities and even old-established ERP components are suddenly presented as a proper bank specific solution.
So let’s outline first what is really meant by SAP Banking Services. Of course you will find Sales, Accounting or Compliance topics branded as banking products – but these in the end are cross industry solutions. So what is really Bank specific?
The two main blocks that are combined on the Banking platform are Operational Banking (meaning Core or Transactional Banking) and Analytical Banking.
SAP Banking Platform
 
Maybe this picture is more familiar to you:

SAP Transactional Banking
 
So for Banking Services, let’s exclude all Business Support Modules and focus on SAP Core Banking Modules:
Contrary to the ERP Solutions SAP-CML and SAP Deposits, the two modules DM/LM are included within the Banking Services Platform with its own runtime environment and full integration from an accounting architecture point of view.
The other Pillar for SAP Banking Services is Analytical Banking with its apparently own modules (see picture above). And here is where the drama begins. Does this graphic imply that there is a designated module for Risk, Accounting or Asset/Liability Management? Of course solutions such as Governance, Risk and Compliance (SAP GRC) or Business Objects partly cover these areas, Risk, Regulation and Analytics, but in this case there is a Bank specific Tool which unifies these Business functions within one single Solution – the Bank Analyzer. 
SAP Bank Analyzer

SAP Bank Analyzer provides a modular, service-oriented, integrated finance and risk architecture (IFRA). It supports overall bank controlling by calculating, evaluating, and analyzing financial products.” (Source: SAP). This is the part where the Bank Analyzer lives up to its name - Analyzer. However, in addition, it is also the designated Sub-ledger for Bank specific products, following the approach of a fat Sub-ledger with all transactional detail and a thin General Ledger with aggregated data.
Does Bank Analyzer also equal to Sub-ledger for Banking? Maybe it is this unfortunate naming that puts this powerful tool in the analytical on-top corner and suppresses its real capabilities.
When deep diving on the Bank Analyzer – in expert articles, blogs, service provider offerings or even SAP in-house documentation – you will often find the same spoon-fed descriptions and images, which in my opinion are little concrete and leave this jack of all trades device in the nirvana of functional specifications. To break it down and make this tool tangible, the main application areas for the Bank Analyzer are:   
Accounting/Sub-Ledger:
  • Financial Accounting
  • Management Accounting
  • Profit Management
Risk Management:
  • Credit Risk (Basel II)
  • Asset/Liability Management
  • Limit Management
  • Regulatory Reporting
In the next posts we will get into detail and explain what’s behind each of above mentioned functionalities – for now I just want to give a basic understanding, so this black box loses its mystery.
Let’s also scan and skim the general layer model (next illustration) - or so called Integrated Finance and Risk Architecture (IFRA), which provides a single point of truth and ensures that original data, methods and valuation results are clearly separated.
SAP Bank Analyzer
 
Let’s focus on the above mentioned core areas Accounting and Risk and their respective Architecture.
Accounting Architecture:
Accounting Architecture SAP Bank Analyzer
 
Risk Architecture: 
Risk Architecture SAP Bank Analyzer

At first sight both figures above might look packed, but they illustrate pretty good the main components of the Bank Analyzer and map the Accounting and Risk functionalities to the respective data layers.
In the Accounting Architecture for example you can follow the data flow, coming from the core systems, such as Deposits or Loans and other source systems, being stored in the Source Data Layer (SDL) as primary objects.
The marked components in light blue in the Process & Methods Layer (PML) are the actual centerpieces, containing the accounting and valuation rules for creating postings, validating and enriching the data.
Via the Results Data Layer (RDL) and the GL Connector within the Analytical Layer, (AL) the financial data is prepared and aggregated before handed over to the General Ledger.
Same scheme applies to the Risk Architecture, whereas the focus here is on Credit Risk and meeting Basel II requirements and other risk related functionalities such as the calculation of a vast number of key figures, stress testing and the Limit Manager.
In the next posts we will see both Architectures and their specific functionalities more in detail.

jueves, 7 de febrero de 2013

Reporting & Compliance


Reporting & Compliance

Debido a la crisis financiera, la Unión Europea está llevando a cabo una profunda reestructuración de sus autoridades. En este contexto surgen no solamente requerimientos nuevos para los bancos, sino que también se pretende llevar a cabo la armonización tanto de la normativa, como de su supervisión final a nivel europeo.
Para estos fines es necesaria la implantación de un estándar técnico unificado a nivel internacional, definido por la EBA (European Banking Authority), con el objeto de garantizar la máxima transparencia y permitir la comparación de las entidades.
Debido a que los bancos no informan directamente a la EBA, sino a través de las NBAs (National Banking Authorities), se suponen menores cambios nacionales (del tipo “add ons”) con el fin de cubrir los requerimientos adicionales de las leyes nacionales.
Los datos generados incluyen tanto la CRD IV como la CRR y detallan las especificaciones de Basilea III (COREP), el Reporting Común del Libro de Mayor y las Pérdidas y Ganancias (FINREP) respectivamente.
El lenguaje técnico es XBRL, que se basa en un Data Point Model (DPM) definido por la EBA.
El  Risk Analyzer de SAP Bank Analyzer proporciona el cálculo, análisis y valoración de los productos financieros para obtener los riesgos asociados (market risk, credit risk, y operational risk). Además, permite la ejecución de las pruebas de estrés (stress testing) bajo las condiciones seleccionadas por el usuario. Al mismo tiempo y junto con SAP BW, garantiza la generación de los informes en XBRL (COREP), adaptándose de forma rápida a futuros cambios o nuevos requerimientos.
AFI (“Accounting for Financial Instruments Solution”), que forma parte de SAP Bank Analyzer, está capacitado para llevar a cabo los cálculos y valoraciones de informes del Reporting Común (Informes FINREP, basado en IFRS).