Postilion User Training

Presentación del tema: "Postilion User Training"— Transcripción de la presentación:

1 Postilion User Training
EFT and ISO8583 Postilion Realtime Framework PostCard Postilion Office ATM Driving Marzo, 2010 Ing. Gonzalo Barbosa Berján

2 Postilion User Training
EFT and ISO8583 Postilion Realtime Framework PostCard Postilion Office ATM Driving Modulo 1a Electronic Funds Transfer Marzo, 2010 Ing. Gonzalo Barbosa Berján

3 Sobre este módulo Conoceremos los términos usados en la industria de la Transferencia Electrónica de Fondos (EFT, siglas en inglés), pues son los términos para describir las actividades con transacciones electrónicas. También nos referiremos a la normatividad ISO8583, sus partes y como se relaciona con EFT.

4 Sobre este módulo Como primer idea, podemos “inicialmente” relacionar los retiros con Cajeros Automáticos (ATM) o relacionar las compras con Puntos de venta (POS). Existiendo desde luego muchos tipos de transacciones actuales (consultas, compras virtuales, transferencias, pagos, depósitos, etc) y serán motivo de este módulo

5 Sobre este módulo EFT, es comúnmente el proceso de transferencia de dinero en forma electrónica de una cuenta a otra, sin intervención manual regularmente en el momento para dar una aprobación. Concepto cada día con mayor amplitud y mayor detalle

6 Sobre este módulo Hoy en día su funcionalidad incluye pagos de servicios, transferencias a terceros, pagos ACH, recargas de celulares, compras de pasajes. Todo con los respectivos convenios y parámetros de negocios preestablecidos.

7 Conceptos y términos EFT
Card Holder, en términos simples es el dueño de la tarjeta o según el caso dueño de la cuenta Card Acceptor, comunmente es el comercio o almacén que acepta un Card Holder para que aquí inicie una transacción. Ya es común que una sucursal bancaria lo sea cuando la tarjeta no le pertenece. En todo caso siempre deben existir convenios.

8 Card acceptor (Aceptador de tarjetas)
Conceptos y términos EFT Card acceptor (Aceptador de tarjetas) Es un establecimiento o negocio que acepta tarjetas plásticas para pagos de alguna naturaleza (Compras, prepago) Algunos de estos Aceptadores de tarjetas se les reconoce como Merchant (Comerciantes). Para definir a un Merchant, debe primero entrar en un convenio con un adquiriente, y este es quien procesará sus transacciones. Almacenes Cinemas Sitios de diversion Restaurantes

9 Conceptos y términos EFT
Adquirer, es el proveedor de la cuenta del almacén, o en caso la institución financiera encargada de administrar la cuenta. Card Association, son las instituciones comunes como VISA, MasterCard, American Express, etc que emiten o administran tarjetas y enrutan las transacciones, controlando Comisiones y otros valores

10 Conceptos y términos EFT
Issuer, puntualmente es el ente que emitió la tarjeta y el responsable de aprobar o declinar transacciones (Salvo que delegue este control a entidades previos convenios) Authorization, acción tomada regularmente por el Issuer, basados en condiciones de seguridad, saldos y condiciones predefinidas

11 Conceptos y términos EFT
Primary Account Number (PAN), es el número de la tarjeta usada, asociada a una o varias cuentas del Card Holder, su tamaño regular es dígitos Bank Identification Number (BIN), Normalmente los primeros 6 dígitos del PAN, y lo usan las entidades para conocer el tipo de enrutamiento, Cliente propio o externo

12 Conceptos y términos EFT
Point Of Sale (POS), típicamente usado para que el Card Holder realice compras en establecimientos. Hoy en día poseen mas funciones. Automated Teller Machine (ATM), típicamente usado para hacer retiros de dinero y consultas de saldos. Pero igualmente sus usos actuales son amplios

13 Diagrama de componentes
ATM / POS NODE NODE NETs Cards SWITCH RealTime NETs Issuer Cardholder WEB

14 Ejemplos de transacciones EFT
Hoy día la aplicabilidad del EFT es muy amplia, desde las tradicionales consultas de saldos y avances, hasta procesos programados automáticos por entidades, hacer reservas o compras en línea de servicios o productos como telefonía prepago, pasajes, boletería, etc. La funcionalidad tradicional mas usada : Consultas de saldo o consulta de cupo Retiros o avances Compras o anulaciones desde un POS Transferencias de fondo

15 Ejemplos de transacciones EFT
Sin embargo desde hace años, se ha implementado nuevas transacciones que hacen cada vez útil y mas ágil la vida. No son solo los bancos quienes ahora poseén esta funcionalidad, ni son los únicos que tienen POS o ATM propios para captar transacciones. Hoy día hay entidades comerciales que han visto en esta funcionalidad un medio muy útil para ofrecer mejores servicios que facilitan el día a día.

16 Muy similar a un ATM, pero en los
Ejemplos de transacciones EFT Desde POS (Datáfonos) Muy similar a un ATM, pero en los retiros o depositos, se deben hacer con apoyo presencial de una persona Desde Internet Similares a las ya dichas, pero con las ventajas de dar un excelente detalles de la transacción y cualquier computador con Internet se vuelve una terminal virtual (Usando Páginas seguras, https)

17 Ejemplos de transacciones EFT Desde IVR (Interactive Voice Response)
Aqui la limitante es la capacidad de texto a leerse en cada menú ofrecido en las preguntas o durante las Respuestas. La respuesta desde luego es una frase que indique si la transacción fue satisfactoria o negada Al no haber recibo físico, muchas de las transacción no son de gran aceptación por este medio por los clientes. Aunque algunos usan el FAX

18 Redes Switch Las REDES son muy importantes en procesos EFT, porque son la guía de interconexión de “Issuer”, “adcquirer”, “Merchant” y los “Card Holder”. Estan en capacidad del envío y enrutamiento de las transacciones de POS y ATM, de o hacia una entidad. Credibanco y Redeban, en Colombia Suiche7b, CCC, Corpbanca en Venezuela ATC en Bolivia, BanRed en Ecuador, etc

19 Conclusiones EFT EFT, es cualquier transacción dada por medio electrónico como un ATM, POS, Internet o IVR Las partes involucradas siempren interactuan en conjunto y según el caso una entidad puede ser definida como Acquirer o Issuer Las validaciones en EFT varían si hay o no presencia de tarjeta, para validar una clave, una cédula, una huella, etc

20 Preguntas

21 Postilion User Training
EFT and ISO8583 Postilion Realtime Framework PostCard Postilion Office ATM Driving Modulo 1b ISO8583 Standard Ing. Gonzalo Barbosa Berján

22 Estándar ISO8583 Las partes involucradas en un proceso EFT requieren de un idioma común para poder interactuar entre si. En esta industria, existe un estándar que rige esta mensajería y es por el que Postilion se rige. Es el ISO8583 (The International Standards Organization’s specification for Bank Card Originated Messages)

23 Estándar ISO8583 ISO (International Standards Organization) ISO8583 fué preparado por el comité tecnico ISO/TC 68. Este estándar contiene las especificaciones para el intercambio de mensajes originados por tarjetas bancarias.

24 Estándar ISO8583 Hay definiciones para todos los mensajes (Peticiones y respuestas) y sus elementos contenidos, desde y hacia Postilion. Estas definiciones son basadas en el estándar ISO8583 (Ago-1987, usado por Postilion) para mensajes originados por tarjetas bancarias y todos los nuevos esquemas hoy día usados Un mensaje se forma de tres partes.

25 Estándar ISO8583 El Campo “Tipo de mensaje” son los 4 primeros dígitos y se compone a su vez de: Clase de mensaje, Primeros 2 digitos. Funcionalidad, últimos dos dígitos.

26 Mensajes con mayor uso Mensajes Transaccionales 0100/1 – 0110
Authorization Request Authorization Response 0100/1 – 0200/1 – 0220/1 – 0420/1 – 0800/ Transaction Request Transaction Response Transaction Advice Transaction Advice Response Reversal Advice Reversal Advice Response Network Management Request Network Management Response

27 Mensajes Transaccionales
Mensaje Authorization Request. Solicitud de autorización Utilizado para solicitar una autorización (no usado para mover dinero). Es originado por quien adquiere la transacción y es enviado a una interfaz para que la autorice (sink node). Mensaje Authorization Response. Respuesta a una solicitud de autorización Utilizado para responder a una solicitud 0100 o 0101 previa. Es recibido de la interface que atendió el mensaje original (sink node). Y es enviado a la interfaz de la petición (source node)

28 Mensajes Transaccionales
Mensaje Transaction Request. Solicitud de transacción Utilizado para solicitar transferencia de fondos. Es originado por quien adquiere la transacción. Es enviado a la interfaz para que autorice (sink node) Mensaje Transaction Response. Respuesta a solicitud de transacción Utilizado para responder a un mensaje 0200 o 0201 previo. Es recibido de la interface que atendió el mensaje original (sink node), O del Switch si fué atención en Stand-in. Y es enviado a la interfaz que hizo la petición (source node).

29 Mensajes Transaccionales
Mensaje Transaction Advice. Notificación de transacción Utilizado para notificar que se ha efectuado una transacción a nombre de esa entidad. El mensaje solo es recibido del ente que autorizó en forma exitosa para aplicar lo autorizado, o declinado para contar que un mensaje fué declinado. Mensaje Transaction Advice Response. Respuesta a una notificación de transacción Utilizado para responder a un mensaje 0220 o 0221 previo. Es respondido siempre por el switch y luego enviado un mensaje 0220 al sink node respectivo.

30 Mensajes Transaccionales
Mensaje Reversal Advice. Notificación de reverso Para revertir total o parcial una transacción previa. Es enviado al ente que previamente autorizó o se le envío una petición y que por tiempo o falla se necesita ahora reversarse Mensaje Reversal Advice Response. Respuesta a la notificación de reverso Utilizado para responder a un mensaje 0420/1 previo. Siempre es respondido por POSTILION hacia el ente que solicitó el reverso, y luego según la respuesta o configuración del TM se hace los respectivos reintentos.

31 Estructura del ISO8583 El segundo componente del mensaje es 1 o 2
BITMAp, cada uno compuesto por 64 BIT. Cada BIT es presencia (1) o ausencia (0) en el mensaje de un campo. El BITMap primario (bit 1-64), siempre estará presente. Para usar BITMap secundario (bits )se indicada activando el BIT 1 en BITMap primario

32 7---2---3---E---4---4---8---1---2---8---E---0---9---0---0---1---
Estructura del ISO8583 Un ejemplo de esta estructura es: E E 723E448128E09001 Los Campos presentes son 2, 3, 4, 7, 11, 12, 13, 14, 15, 18, 22, 25, 32, 35, 37, 41,etc El primer dato, el “7”, indica que el BIT 1 no Está (0111), por tanto si hay uso del MAC, este debe estar en el BIT 64.

33 Estructura del ISO8583 El contenido de los datos en la tercer parte del mensaje, es hecha por la union de una serie de campos con información definida al enviarse. Los mensajes son reconstruidos usando el BIT Map. Algunos campos son de longitud fija, mientras que otros campos tienen longitud variable. Estos últimos, poseen antes de cada campo la longitud del mismo en formato fijo para saber con que tamaño leerlo.

34 Campos ISO8583 mas usados Campo Nombre 2 Primary Account Number 3
Processing Code 4 Amount Transaction 7 Transmission Date and Time 11 System Trace Audit Number 12 Time, Local transaction 13 Date, Local transaction 14 Date, Expiration 15 Date, Settlement 18 Merchant Type 22 POS entry mode 25 POS Condition Code 35 Track 2 Campo Nombre 37 Retrieval reference number 38 Authorization ID Response 39 Response Code 49 Currency Code 52 PIN Data 54 Additional Amounts 70 Network Management Information Code 95 Replacement Amount 100 Receiving Institution ID Code 102 Account identification 1 103 Account identification 2 127 Postilion Private Field

35 Ejemplos de campos en mensaje 0200
Campos ISO8583 mas usados Ejemplos de campos en mensaje 0200 [May 26 09h49:19.577]-<0200> Message to Transaction Manager . . . 0200: [Fixed n ] 003 [012000] [None n ] 004 [ ] [Fixed n ] 007 [ ] [Fixed n ] 011 [000761] [Fixed n ] 012 [104919] [Fixed n ] 013 [0526] [Fixed n ] 018 [6011] [Fixed n ] 022 [901] [Fixed n ] 025 [00] [Fixed n ] 026 [12] [LLVAR ans ] 035 [ = ] [Fixed ans ] 041 [ ] [Fixed ans ] 042 [001LAB EJEMPLO ] [Fixed ans ] 043 [CIUDAD EJEMPLO PRINCIPAL …… CUCO] [Fixed a/n ] 049 [170] [Fixed b ] 052 *[94FD71EF9EED2594] [LLLVAR an ] 123 [ ] [LLVAR ans ] [ ] [LLVAR ans ] [BancoEJEMPLO] [Fixed ans* ] [ ]

36 Campos ISO8583 mas usados Ejemplos de campos en mensaje 0800
[May 2 9h50:05.577]- <0800>Message from Interchange [ ,260] 0800: [Fixed n ] 007 [ ] [Fixed n ] 011 [000011] [Fixed n ] 053 [ ] [Fixed n ] 070 [162] [LLLVAR ans ] 120 [D248 ] [LLLVAR ans ] 123 [CSM(MCL/KSM RCV/ ORG/ KD/5990B018C3902F8C CTP/ A2 ) ] Ejemplo de un mensaje con muy poco campos [May 6 7h50:05.577]- <0800>Message from Interchange [ ,260] 0800: [Fixed n ] 007 [ ] [Fixed n ] 011 [000020] [Fixed n ] 070 [301] Interactuar con estos mensajes hacia algunas redes, exije agregar un encabezado especial Base24

37 Formato de los campos La normatividad ISO8583, hace desde luego exigible que TODOS los campos tengan definido el tipo de datos que contiene, incluyendo el tamaño máximo posible para el caso de los BIT que son variables

38 Formato de los campos Para el caso de los campos variables, el ..LL o el ..LLL indica que ese campo usará al inicio 2 o 3 dígitos para indicar el tamaño que trae. Es decir ..LL, para indicar poder decir o 37

39 (2) Primary Account Number
De longitud máxima de 19 dígitos numéricos Resaltado frente a la tarjeta y codificado en el Track2 de la banda magnética El PAN se compone de 3 elementos generales. El Código del emisor (issuer identification number “IIN”) El identificador de cuenta individual Dígito chequeo (Calculado con el Check Luhn)

40 (2) Primary Account Number
Código emisor (Issuer Identification Number “IIN”) Este es el llamado BIN de la tarjeta, poseé regularmente 6 dígitos que identifican a un emisor de tarjetas en el mundo transaccional. De esta forma las redes saben si la tarjeta adquirida en sus dispositivos debe tener enrutamiento local, nacional o internacional Para enrutamiento internacional, las redes de cada Pais tendrán igualmente tablas para saber a que lugar del mundo se enrutan los grupos de BINes de tarjeta BANCO amigo Gonzalo Barbosa Comunmente 4XXXXX VISA 5XXXXX MASTER

41 (2) Primary Account Number
Dígito de chequeo (calculado con el Check Luhn) El ultimo digíto regularmente corresponde a un calculo matemático que se muestra en el siguiente ejemplo: Se dobla el valor de cada digito intercalando la posición impar, comenzando por el ULTIMO dígito Se suman por separado los digitos de los valores mayores a 9, resultantes de doblar los digitos impares Se obtiene al final la totalidad de dicha suma y se resta del siguiente multiplo del 10 que obtuviese por encima, donde el residuo es el digito de chequeo * 4x x x x x2 + 0 + 0x x x2 = * = – 53 = “7”

42 (3) Processing Code Con tamaño fijo que consiste de 3 elementos
Transaction type (1-2) From Account type. Tipo cta debitar (3-4) To Account type. Tipo cta a acreditar (5-6) Postilion puede descartar mensajes donde el tipo de transacción no esta permitido para el tipo de cuenta que llega. Ej. Transferencia para cuentas de credito

43 (4) Amount Transaction Es el monto requerido por el cliente en una de las monedas locales donde se localiza el originador de la transacción (Físico o virtual). Los valores SIEMPRE expresados en la menor denominación (Centavos por ejemplo). n12: = $ oo Donde los ceros finales son los centavos en la moneda que se represente Para conocer la denominación en que llega este valor, se usa el valor del campo 49

44 (11) System Trace Audit Number
Es el campo comúnmente usado para asignar el consecutivo de la transacción en una terminal. Este junto con el código de la terminal, en un día puntual puede servir de identificador de la transacción Este valor es regresado a cero bajo 2 aspectos en los ATM administrados por Postilion (ATMApp), al finalizar el dia contable, o al llegar el máximo valor posible (a 6 digitos de )

45 (12) Time, Local transaction
Es el campo que identifica la hora original de la transacción. Cuando se tiene transac. Internacionales este campo varia del campo 7 sumando o restando la hora GMT HHMMSS es la representación de este campo. Donde existe administración de ATMAPP, este campo es el MISMO de la hora en el servidor POSTILION

46 (13) Date, Local transaction
Es el campo que identifica la fecha original de la transacción. Coincide con el campo 7, pero si la transac. no esta próxima a la media noche. MMDD es la representación de este campo en línea. Pero cuando se hace registro de fecha completa el sistema reconoce el año a 4 digitos

47 (14) Date Expiration Es el campo que identifica la fecha de vencimiento de la tarjeta. Debe coincidir de estar presente con el subcampo de track2 en el campo 35 YYMM es la representación de este campo en línea. Pero usualmente se graba sobre el plástico de la tarjeta en forma opuesta MMYY* (Aspecto netamente visual)

48 MMDD es la representación de este campo en línea
(15) Date Settlement Es el campo que identifica la fecha contable o de negocio de la actual transacción. Es el mismo campo 17 en BASE24. Postilion usa un esquema de Calendario de negocio con corte de hora programada a diario, Aunque puede trabajarse feriados entre cortes contables MMDD es la representación de este campo en línea

49 (22) Pos Entry Mode Método de captura de la tarjeta y fecha expiración cuando lo usa la terminal. Junto con la capacidad para capturar el PIN en la terminal (Obligatorio o no) Tamaño fijo de 2 elementos: PAN entry mode (posición 1 - 2) 02 y 90 usados en ATM y POS, regularmente PIN entry capability (posición 3) 1 que cita que acepta PIN No es usual ni recomendado que llegue con valor “000”

50 (25) Pos Condition Code Un código que describe la condición
bajo la cual la transacción fue captada en un punto de servicio.

51 (28) Amount, Transaction Fee
Es la comisión (Surcharge) que carga el adquiriente al Emisor, por un tipo de transacción realizada en su ambiente. Se puede configurar cobros distintos por retiros, otro valor en consulta o transferencia x + n8: D = $ 15.oo Donde los ceros finales son centavos como cualquier monto estándar en POSTILION. Para conocer la denominación en que llega este valor se usa el campo 49

52 (35) Track 2 data Es un campo de tamaño variable hasta un maximo de 37 caracteres. Es la información codificada en el track2 de la Tarjeta físicamente ubicada en la banda magnética definida por el ISO7813 El subcampo separador entre el PAN y la fecha de expliración puede ser “=” o una “D” Campo Formato Tamaño Primary Account Number Numerico .. 19 Field Separator No numerico D o = 1 Expiry Date YYMM 4 Service Restriction Code 3 Discretional Data 13

53 (35) Track 2 data Cuando hay transacción con BANDA este campo
se hace obligatorio, si el campo 2 esta presente DEBE tener el mismo valor en la parte del PAN Ejemplo Track2: = Código de Restricción PAN Fecha Expiración CVV =

54 (38) Authorization ID Response
Es el campo presente en los mensajes de respuesta aprobados por un autorizador Algunos mensajes 0220 llevan este campo citando con que AUTORIZACION se dio una anterior transacción. El campo 29 es este caso debe estar aprobado total “00” o parcialmente “08, 10, 11”

55 Field Private 127 Este es un campo adicionado específicámente a Postilion con respecto al ISO8583 estándar. El campo 127 poseé su propio BITMap (127.1) para indentificar que subcampos trae. Son identificados como 127.xxx Y xxx es el subcampo

56 Most used fields (127.x) 127.2 El campo switch key es el identificador UNICO de cada transacción en el Swith Postilion. Cada nuevo mensaje de un nodo Source, debe enviar una nueva transacción con un único identificador en el gran del LOG de Postilion: tm_trans Si se da un reverso este campo es el buscado para identificar si la original esta registrada y ver si fue aprobada para realmente hacer un reverso 127.8 Se usa para pasar datos transparentes del Source al Sink y viceversa. Este campo hace que se registre información en la tabla tm_trans_retention_data

57 Most used fields (127.x) Original Swith Key Es usado solo en reversos y es la llave que se usa para poder ubicar una transacción original de un mensaje anterior, e identificar si fue aprobada para proceder a reversarlo Cuando este campo llega en ciertos mensajes, Postilion hace la autenticación de la cedula, mediante el campo “validation information” en la tabla de tarjetas. Esta información es una herramienta en ciertas transacción para aplicar una validación de seguridad y detectar si dicho valor es diferente al registrado a esa tarjeta. De ser asi, se declina la transacción

58 127.22 El campo Structured Data. Usado
Most used fields (127.x) El campo Structured Data. Usado para tener información subagrupada, que se puede identificar localizando uno de los key que existen. El campo provee flexibilidad en el transporte de datos 2 Ejemplos: 19NombreKey215ValoresDelValue 12K115Data112K214Dat214Key315Data3

59 Normatividad Base24 La mensajería externa BAse24 es basada en ISO8583 (1.987), tiene tamaño variable y su contenido depende el mensaje que se use.

60 Base24 Header

61 Preguntas