Business canvas mixture for (formely) Yapp (now DiveDot)

Generating Ideas

  1. What are the potential ideas that can be represented to solve the customer?s problem?
  2. What is the closest manner to solving the customer problem among the existing solutions in the existing market?
  3. Do you think the ideas you prepared were deduced much enough?
  4. Categorize innumerably deduced ideas into three themes.
  5. What are the ideas that finally passed when they were evaluated in the aspect of customer and company?
Website (under construction)

This canvas is more a "reflexion board" in french - mother tongue - language )

The real business canvas in English version is here:

https://canvanizer.com/canvas/ri5piYI26liXm

formely

https://divedot.com/

now

https://social2pay.com

Growth hacking

https://twitter.com/MonkeyTime7711

Official

Twitter: https://twitter.com/DiveDotPay
Facebook: https://www.facebook.com/DiveDot
linkedin: https://www.linkedin.com/company/divedot

DiveDot "right message"

Right message: Pay securely with your social account, with ease as never viewed before.

Automated or in one click.

Right message for corporate bank: The "paypal like" web and network tools as a "white brand/label" for all banks.

Resumé (vulgarisation) step by step - fr

Yapp permettra à chaque banque ayant une interface bancaire en ligne de proposer, comme Paypal le fait, des APIs et donc un système de paiement distribué aux « pros » du web et ce de façon entièrement transparente.

Chaque « pro » du web aura l'impression que c'est parfaitement transparent et distribué par SA banque.

Chaque banque, grâce à Yapp, proposera des boutons très simple à intégrer sur un site web ou une application, qui diront...

« Pay with Facebook ».

De la même façon qu'actuellement vous avez « Connect with Facebook » sauf

qu'avec « Pay with Facebook » (« Pay with Twitter », « Pay with Youtube », ...) évidemment on ne se connecte pas, on paie.

On paie : un achat online
On paie : pour voir du contenu payant (livres, films,...)
On paie : pour des achats virtuels (InGame, billetteries virtuels, ...)



Qu'est-ce que la structure de Yapp permet ?

Grâce à ce principe reposant sur les principales APIs (Facebook , Twitter, linkedin, Youtube, google+, instagram, ....), peut importe. Toutes celles qui permettent de récupérer l'adresse mail.

Chaque banque, grâce à Yapp, proposera, à chacun de leurs acteurs web « pro » (site web ou application) un moyen simple de se passer entièrement de tunnel / funnel de conversion. Evidemment, un paiement traditionnel reste toujours possible, ce n'est que le premier avantage conséquent.

C'est le rêve de toute la sphère marketing qui est résolu grâce à Yapp.

Yapp permet qu'un paiement en ligne se passe entièrement de carte de crédit / débit et de toutes données sensibles.



Cette structure informatique, à la fois distribuée et décentralisée, permet donc...

Un paiement en 1 clic (voir entièrement automatisé quand une chaine de confiance est résolue au moins une fois. On peut donc considérer que c'est un équivalent de notre bon vieux « ordre permanent » que l'on peut exercer à tout instant « T » pour autant qu'une chaine de confiance ai été établie).
De diminuer grandement les coûts pour les banques (0,001 / requête)
Permet à chaque banque de pratiquer sa propre politique de prix « sur mesure » (comme Paypal et d'autres acteurs le font – libéralisation du marché / de la concurrence).
De se passer, partiellement ou entièrement de carte de crédit, débit et données personnelles sensibles.



Techniquement, comment cela se passe ? (Admettons...)

A la date de lancement, les banques déjà partenaires proposent aux professionnels (web et apps) d'intégrer la solution et les boutons via un principe de validation des noms de domaine afin de les associés à leurs propriétaires. Le déploiement est donc assuré.

La banque remonte vers notre structure une url de page de promotion.



Ensuite 2 cas de figure se pose à nous lors d' un achat depuis un site web (ou une app)

Un utilisateur de type «acheteur» (vous, moi, ...) a déjà lié son réseau social à son interface bancaire (si nécessaire +1 FA par soucis de sécurité) afin de valider qu'il est bien propriétaire de l'adresse email fournie par ce réseau social.

Dans ce cas, notre structure, en relation avec chaque banque, vérifie la validité des paiements effectués et un paiement même hors tunnel peut s'effectuer (puisque les boutons «Pay with...» récupèrent l'adresse mail du réseau social qui peut être validée par le marchand par association à un compte existant sur le site web du marchand).


Pour ce qui est de la sécurité

La sécurité s'effectuera grâce à une chaine de confiance (chain of trust) et une chaine de vérités (chain of truth), (à contrario aux chaine de blocks et chaine de responsabilités).

Deuxième cas de figure, l' utilisateur de type «acheteur» (vous, moi, ...) n' a pas encore lié son réseau social à son interface bancaire. Dans ce cas, un clic sur un bouton «Pay with...» sur le site marchand et notre structure renvoi l'information qu' aucun compte n' existe et n'est lié à cette adresse mail et affiche donc ensuite une zone de recherche. L'utilisateur pourra y chercher la page de promotion de sa banque (citée ci-dessus) grâce à son bic/swift/iban/international afin qu'il arrive sur la page de promotion de SA banque afin d'y lier une première (et unique fois) son réseau social (ou ses réseaux sociaux).

Voila, pour vulgariser.

Les possibilités sont infinies puisque beaucoup de chaines de confiances peuvent être établies et donc beaucoup de paiements automatisés peuvent être créés (en déplacement, par géolocalisation, automatique, near real-time,...) et évidement par acte d'achat (web et apps - autrement dit: entre "objets connectés").

Avec DiveDot, plus besoins de carte de paiements - aucune.

START PROCESS

Plus besoins de carte de paiement (débit, crédit, prépayée, à usage unique - aucune). Un simple bouton (de simples boutons) "Pay with Facebook", "Pay with Twitter", "Pay with Youtube", ...

Un clic.

END PROCESS

/!\ à l"ultra" connexion typée de ces réseaux. L'utilisateur pourra, en cas d'ordinateur familial partagé, ajouter depuis sa banque "online" la demande d'un code personnel à chiffres (personnel ou à usage unique) - (associé à/et/ou signature 1FA). Cependant, la bonne pratique voudrait qu'un ordinateur partagé ait plusieurs comptes "utilisateur" (enfant, parent, etc...).

Invalidation depuis son interface de sa banque en cas de perte PC, Portable, SmartPhone, etc... (logique)

NFC (amplifié) - voir "nouveau paiement rfid / NFC" ci-dessous - pour l' "automatisation" (ex: véhicule, péage, etc...). Un hack peut être une opportunité ? (pour l'industrie...)

Un nouveau problème de sécurité dans les paiements en ligne actuel https://fossbytes.com/distributed-guessing-attack-credit-card-six-seconds/

Avec DiveDot, plus de funnel/tunnel de paiement

DiveDot permet de se passer de funnel/tunnel de conversion et de tunnel de paiement. Yapp permet aux acheteurs online de payer à l'achat "non-connecté" à leurs sites web préférés. Yapp s'appuie sur une distribution de boutons spéciaux "Pay with..." - "Twitter", "Youtube", "Facebook", ... que les banques proposeront de façon entièrement transparente (nous ne faisons que fournir aux banques les APIs frontend et backend nécessaires que ces banques redistribueront).

Yapp et sécurité des paiements onlines

A Yapp est associé un concept de géolocalisation des paiements entièrement paramétrable par chaque banque (qui peut donc proposer ce paramétrage à leurs utilisateurs de type "acheteur online" afin de limiter leurs achats à certaines actions "types", par secteurs, par pays, et/ou achats "types" définis par l'utilisateur lui-même quand il le veut, aussi à la modification, et non via un profilage marketing et/ou web de "masse" et "supposé".

Ce sera aux choix de chaque banque suivant leur propre politique de restrictions (qu'elles pourront donc définir "sur mesure": budget, restriction, limitation sur base volontaire, etc...).

Chaque banque remonte donc librement ce type d'information vers notre système décentralisé.

Yapp - système inspiré du glocal, décentralisé et distribué

Yapp est une application "Fintech" de paiement, dédiée aux organismes bancaires, de type "paypal like" que l'on peut considérer comme "marque blanche" décentralisée et distribuée - aux banques - qui proposeront différents aspects à l'intégration - vers leurs clients finaux (web et app professionnels online).

Yapp et les nouveaux modes de paiements RFID NFC

Avec le paiement sans contact (NFC), Yapp permet une validation 2FA par validation de la géolocalisation. 1 clic et une approche des deux appareils sans contact renforce la sécurité des paiements sans contact NFC (l'appareil communiquant par champ F NFC pourra donc fournir une url de paiement générée pour usage unique en se comportant - chaque appareil - comme un émulateur de puce passive NFC "à usage unique").

Note pour moi: ping-pong-validation

Pourquoi renforcer la sécurité ?

https://www.qwant.com/?q=NFC+zéro+day

https://fr.wikipedia.org/wiki/Communication_en_champ_proche#S.C3.A9curit.C3.A9

Une simple application disponible sur internet permet de récupérer par champ proche toutes vos informations de cartes de crédit.

Cette même application associée à un simple amplificateur (2000 euros) et une antenne (1000 euros) disponible dans le commerce, permet de capter toutes les données des puces passives (carte bancaire, carte crédit, votre smartphone ...) dans un rayon d' 1,5 à 3 mètres.

Qu'est-ce que NFC ?

https://fr.wikipedia.org/wiki/Communication_en_champ_proche

Actuellement, l'utilisation de NFC comme mode de paiement ne convainc pas depuis 2014

http://www.clubic.com/pro/e-commerce/paiement-en-ligne/article-728209-1-pourquoi-paiement-contact-nfc-decolle-france.html

Un seul paiement par carte bancaire sur 10 se fait sans contact en 2016 (au mieux et en Angleterre uniquement).

40 ans + d'internet publique ne rend pas encore internet sécurisé, rfid et CCP (NFC) n'ayant que quelques années d'utilisations publiques...

Plusieurs failles zeroday concernant le protocole

en 2012

https://thehackernews.com/2012/09/android-404-multiple-zero-day.html

en 2014

http://blog.nordnet.com/securite-2/faille-de-securite-2/faille-securite-cartes-bancaires-nfc-123.html

en 2016

Des chercheurs Allemands ont trouvés de nouveau une faille grave zéro day dans le protocole d'échange lui-même.

Conclusion

D'après Daryl Plummer

« Les applications ne serviront plus de support marketing de premier ordre pour les grandes marques », a déclaré Daryl Plummer. « Déjà, les apps n’ont pas été à la hauteur des attentes des entreprises », a-t-il ajouté. « Par ailleurs, les boutiques d'applications regorgent d’apps, et il est très difficile de trouver une app vraiment exceptionnelle ou indispensable »

« Les entreprises vont se tourner davantage vers le Web mobile ou feront appel à des « Progressive Web Apps » Les Apps ne vont pas disparaître, mais « nous entrons en quelque sorte dans une ère post-app »

Vive le web ! Et vivement HTTP2.0 (j'ai d'autres projets qui rejoints exactement (certains de) ces propos ...que je ne connaissais pas...).

(source Gartner)

http://www.lemondeinformatique.fr/actualites/lire-10-previsions-du-gartner-qui-vont-marquer-l-it-en-2020-66303.html

D'après @Marcos Caceres (W3C, Mozilla Full Time) dans son tweet de ce 11 novembre 2016 à propos des Progressive Web Apps

https://twitter.com/marcosc/status/796895705805635585

Faudra voir à quelle vitesse çà va être intégré aux navigateurs, les problèmes de sécurités que çà implique (tout en clair dans un user agent ?) et comme çà vient de sortir et que c'est prévu pour HTML51 et la confidentialité des données transmises, est-ce que çà va être bien perçu par les utilisateurs de navigateurs ? rien de sur (et il faudra des années comme pour HTML5 ?)

https://www.w3.org/TR/payment-request/

à contrario, full backend ! No frontend needed pour les informations sensibles (sauf géo et début des lettres et chiffres bic/swift de comptes pour retrouver la banque concernée). Le reste en "front", c'est que de l'UX.

(prévoir quand même ce format...)

La "blockchain"

https://dupress.deloitte.com/dup-us-en/focus/signals-for-strategists/using-blockchain-for-smart-contracts.html?

blockchain secure ?? (les hacks possibles et les millions détournés commence à apparaitre...)

https://www.qwant.com/?q=blockchain+security+breach&t=all

Yapp Global (Payment Solution) et les Play Stores (ios et androïd)

Au vu de la déception des marques concernant les applications mobiles (cout, développement, rentabilité, etc...), la tendance devrait être aux Web apps et progressive Web apps d'ici 2017.

En intégrant une telle solution de paiement (et les Progressive Web Apps) aux différents p(l)aystores, les p(l)aystores devraient avoir l'opportunité d'héberger beaucoup moins de données, de permettre au Web apps et Progressive Web Apps de se développer, tout en continuant leur modèle économique (70/30) dédié au "programme" de reversement financier aux développeurs de jeux et d'activités ludiques, tout en proposant sur ces mêmes "stores" les web app ou les progressives Web apps, par exemple, d'une marque en particulier. Développeurs, p(l)aystores et marques devraient être gagnants.

Problème (hors paiement pour un service) lorsque objet à livrer irl et adresse de livraison changée

Globalisation du processus pour que ce soit un standard adopté (à sortir du contexte de paiement 'un clic") -> SMS ou lien email, valide 30 minutes, pour permettre à l' acheteur de "send" la bonne adresse via un SMS (num. unique / vendor ?) ou en suivant le lien email ou réponse par email... (conservation "locale" des adresses de livraison de l'utilisateur pour "choose" et "send" rapide). L'objet pouvant être "géolocalisé" -> propagation de la bonne adresse chez les différents acteurs.

Sécurité

Envisager un "pluggable" (autoboot + dev), à ajouter aux desktop et laptop, pour accéder à une compatibilité NFC+émulateur des appareils non compatible.

L'émulation à usage unique associé à une url à usage unique fonctionne avec n'importe quel signal (bluetooth, radio, nfc, wifi, etc...) - couches transport

Cooperator for Innovation

  1. Who will you cooperate with for the solution completion?
  2. Is it easy to cooperate with the innovative cooperator?
  3. Don?t you rely on the irreplaceable cooperation?
  4. Aren?t you overlooking although you need cooperation?
OBPI et Soleaux

Idée,
concept et principe de sécurité déposé à l'OBPI (comme mtn c'est
accepté devant tout les tribunaux Européens, pourquoi s'en priver).
Inclus ce document.

Soleaux OK (multi).

Marque et modèles (OK - à déposer)

Technologies envisagées et restrictions

Pour résumé et ne pas m'attarder sur ce point actuellement:

* APIs réseaux sociaux: pas de restrictions
* Centralisation: Apache Kafka (entre autres)

Restrictions légales

Accréditation bancaire: Après analyses des textes de lois, il apparait que, sans rétention d'argent et comme nous ne faisons que faire transiter les données, il n'y aurait pas besoin d'accréditation. Cependant, par sécurité, OVH a été choisi puisqu'il couvre et prend en charge l'architecture scalable nécessaire à nos besoins en serveurs. OVH est accrédité pour les applications critiques sur leur architecture (SOC I, SOC II, ISO 27001 et PCI DSS niveau 1).

Il ne serait plus que nécessaire, dans le pire des cas, d'assurer un audit de sécurité pour obtenir cette accréditation s'il s'avère qu'elle nous serait, à l'avenir et non dans l'état actuel des textes de lois, imposée.

Co-Wallonia

Vérifier les primes et avantages de la région Wallone + Bruxelles.

Phase I: installation St Gilles Liège (bâtiment sécurisé qui me fait de l'oeil et envie personnelle de relancer un peu le quartier) ou Val-Benoît.

Phase II: installation Bruxelles (pressentie, avec une ville de Finlande ?? comme capital city de la finance pour l'Europe) donc urgent d'accélérer le processus de dev.

Do & Test

  1. What action will you take specifically for the practice?
  2. What is the plan for approaching to the initial market?
  3. Isn?t there any problem revealing before the practice?
  4. What resource and ability will you secure?
  5. How will you contact early adaptor?
  6. How will you compose MVP?
  7. How will you conduct A/B test?
Créer un site web

Créer un site web de présentation "produit/service"

POC

faisabilité OK

POC à faire

Contacts linkedin

Contacter des CEO de banques sur linkedin et proposer le lien "produit/service" et le lien privé du POC

Plan d'action

Voir plan d'actions à mener (détaillé étape par étape au format timeline).

Campagnes marqueting

Phase I) Ultra ciblée - CEO banques sur linkedin exclusivement.

Timeline

Respect de la timeline

Devs

à 3 mois essayer d'aller le + vers une version la plus aboutie (POC -> Alpha -> Bêta closed -> production, ...). Phase 1) Stop à 3 mois pour tours de table I - série A - (nécessaire?) et engagement du développeur "white hack" qui travaillera sur la version stoppée mais finalisée, en l'état de sa version.

à toutes les étapes, faire des unitTest + Test avec VM de simulations (couche d' abstraction de lancement de tests unitaires associés, en condition réelle, et couche d'abstraction de test des résultats "croisés" et de détection des anomalies). Bref, créer un "Test Pattern"... (orienté sécurité, volontairement "hackable" ? et résultats afférents - instabilité des updates de BDD NoSQL + rollback...) -> installation d'un framework de test des assertions... (c'est bien ce qu'il me semblait que des tests d'assertions c'est un peu faible et qu'il manquait quelque chose pour les tests d'assertions vu en formation...).

Phase II) Introduction du FabLab d'entreprise. Introduction du HackLab d'entreprise ??

Note pour moi: voir aussi (hors concepts de sécurités nécessaires): ipv6 et protocole + Next Header

Réseaux sociaux

Prévoir une option à activer (automatisation et "sub-second") au cas où les réseaux sociaux ne jouent pas / plus le jeu ou ne peuvent plus jouer le jeu (considération technique, de surcharge (avant: négociation ou politique de reversement), ...).

Indie subsribe process

Is a decentralized process

---- In a web site or an InApp payment process, the user as never activate the link under its web bank account:

1) with its IBAN/BIC/SWIFT/... the payment UX display the logo and the good marketing link of its proper bank to activate it.

---- Now through its web bank interface

1) user link its Facebook, Youtube, etc... (API) account via its Web interface bank account (+1FA or others security tech/purpose/check)

2 Through already its web bank interface, the bank propose limitations (on demand or personnalized), limitation by geolocalization, etc... payment (or other cool stuffs you can read elsewhere in this business canvas document).

Now it is activated!

Cooperator for Market

  1. Who will cooperate with for the market advance?
  2. Is it easy to cooperate with market cooperator?
  3. Don?t you rely on the irreplaceable cooperation?
  4. Aren?t you overlooking although you need cooperation?
Banques

Convaincre les banques d'intégrer le projet, (et un processus d'intégration strictement nécessaire), à leurs propres "business model"...

Avantages pour les banques et argument produit: pouvoir facturer ce qu'elles veulent et pratiquer leur(s) propre(s) politique(s) de prix / sur mesure / par client / par type de client / par rendement d'activité pro / par CA de leur client / par accompagnement personnalisé à la création d'entreprise "web", corporate, international, etc....

Banques

Nous assurer de "pré-engagements / promesses" auprès des banques. Assurer, via notre site web, l'acquisition de statistiques sommaires et par banque (évaluation des ventes onlines de leurs nombreux clients "pro du web" / mensuellement), ou, trouver ces statistiques pour pouvoir rationaliser/évaluer nos besoins au démarrage (principalement coût architecture OVH, prévision de la scalabilité pour pouvoir assurer l’absorption de charge et donc évaluer la quantité de serveurs par VPN à louer).

Ceci, pour mieux définir nos besoins pour les 3 premiers mois d'activités (avant facturation).

Customer

  1. Who is my core customer?
  2. Who is my non-customer (STB, rejecting, potential)?
  3. How is the customer segment divided?
  4. How can you define persona?
B2B banques

Les API seront distribuées aux banques.

Les banques, proposeront, au lancement, les différentes API (front et back) à leurs partenaires professionnels (web sites et apps).

B2B2B (B2B indirecte)

Ces mêmes partenaires professionnels du web pouvant travailler directement avec leurs banques respectives se verront proposer l'intégration des boutons "Pay with Google", "Pay with Facebook", "Pay with Twitter", "Pay with Youtube", "Pay with... any API", etc... directement par leurs banques respectives. Option d'activation ou non par API (logique) / dns|ip

B2B2B2C (the lol effect)

L'objectif à plus long terme est que Yapp devienne indispensable (disruptivité intrinsèque à la facilité d'utilisation) afin que même les réseaux sociaux utilisent les boutons. Ainsi en décentralisant leurs propres paiements, même ces réseaux sociaux pourront intégrer ces boutons et ajouter des contenus payants (ex: les réseaux sociaux pourraient envisager un partenariat avec l'industrie du cinéma pour, par exemple, remonter vers ces réseaux sociaux du contenu "payant" cinématographique "vieillissant").

Problem

  1. What is my customer?s unsatisfied need?
  2. Is the customer aware of that problem?
  3. Is the customer aware of it as a fully important problem?
  4. Are competitors also aware of that problem?
  5. How has the customer solved that problem before?
Labeur pour l'utilisateur du funnel / tunnel
Les systèmes de paiements qui se multiplient
Complexité des intégrations (qui se multiplient)
Complexité et problèmes pour un owner site/app web "pro" avec le funnel / tunnel diminuant les taux de conversions
monopole(s)

effet indirecte de "libération du marché" pouvant aller croissant comme décroissant via "politique de prix sur mesure" via libre concurrence mais marché exponentiel (5.8 billions internet users expected in 18 months)

Solution

  1. Did core solution come out as a result of idea conception?
  2. What is consequently my value proposal on the problem the customer has?
Avec Yapp, le funnel/tunnel devient vraiment optionnel

Grâce aux boutons "Pay with...", toutes personnes ayant un compte sur un site web ou une app peut se passer de funnel/tunnel et faire des achats "en tant qu' utilisateur non-connecté" (CQFD: à l'application / au site web visité) - pour autant qu'il se soit créer un compte préalablement avec la même adresse mail (ou un bouton "Connect with..."). Yapp résout donc le rêve jugé inatteignable (de se passer de tunnel de convertion/paiement) de la communauté marketing mondiale.

Système de paiement décentralisé permettant une recentralisation des échanges "web" vers les banques.

En décentralisant les échanges de données entre sites web / apps professionnels et leurs utilisateurs (comme le fait par ex Paypal), Yapp permet aux banques de se centrer sur leur core business concernant les paiements onlines (accompagnement d'indépendants, de commerçants, etc...), tout en permettant aux banques et applications de paiements existantes de faciliter leurs échanges en intégrant la solution. Pas de concurrence pour Yapp puisque même une solution de paiement existante peut intégrer les boutons de paiements et se "reconnecter" directement à sa banque (qui facturera les échanges suivant sa propre politique de prix qu'elle peut définir "sur mesure").

Liens utiles (production env et dev env)

Régulateur EU / EN

https://www.fca.org.uk/firms/fintech-and-innovative-businesses

https://www.handbook.fca.org.uk/handbook/PERG/2/7.html

https://www.fca.org.uk/firms/project-innovate-innovation-hub/test-customer-communication-ideas

http://www.mas.gov.sg/News-and-Publications/Media-Releases/2016/MAS-Proposes-a-Regulatory-Sandbox-for-FinTech-Experiments.aspx

Régulateur EU / EN "sandbox"

https://www.fca.org.uk/firms/project-innovate-innovation-hub/regulatory-sandbox

Accessoirement - J'ai la sandbox du régulateur BE.


Near future (expected ??)

https://w3c.github.io/browser-payment-api/specs/architecture.html

https://w3c.github.io/browser-payment-api/specs/architecture.html#dfn-payment-method-identifier

https://www.w3.org/TR/payment-request/

https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

Mastercard et Visa (json result example)

https://developer.visa.com/reference

https://developer.mastercard.com


Service workers

https://www.talater.com/upup/

https://serviceworke.rs/

FaaS (for extra services (SaaS) - open to APIs developers - also when already API exist "free" or "with charge" -> full repayment polic(y)ies and billing also by request)

http://martinfowler.com/articles/serverless.html

Prévisionnel financier

http://www.commentcreersonentreprise.fr/comment-etablir-un-previsionnel-financier


EUROPA banking authority

https://www.innopay.com/blog/psd2-xs2a-what-you-need-to-know-about-the-discussion-paper-of-the-european-banking-authority/


Some basis

https://connect.interswitchng.com/documentation/integration-overview/#json-rsp


DBs et caches

http://kafka.apache.org/

https://hazelcast.org/use-cases/caching/#elastic-memcached

https://cwiki.apache.org/confluence/display/KAFKA/Clients

http://flink.apache.org/

http://orientdb.com/

http://nosql-database.org/

http://hypertable.com/documentation/

http://www.project-voldemort.com/voldemort/quickstart.html

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB

https://redis.io/

https://redis.io/topics/lru-cache

https://github.com/petersirka/nosql

https://github.com/kripken/sql.js

http://www.mongodb.org/

http://cassandra.apache.org/


VRAC (Java, PHP, C#, network, infos,...)

http://akka.io/

https://www.rust-lang.org/fr-FR/

https://youtu.be/FfoXFnzZbBM?t=3m49s

https://github.com/iron/iron

https://www.npmjs.com/package/crypto-js

https://www.iprhelpdesk.eu/ip-sme-corner

http://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1447773803386&uri=CELEX:52015DC0192

https://fr.pcisecuritystandards.org/minisite/en/

https://fr.wikipedia.org/wiki/Norme_de_sécurité_de_l’industrie_des_cartes_de_paiement

https://www.graylog.org/use-cases

http://php.net/manual/fr/intro.xhprof.php

https://hadoop.apache.org/docs/r2.7.1/hadoop-yarn/hadoop-yarn-site/YARN.html

https://ci.apache.org/projects/flink/flink-docs-release-1.1/concepts/concepts.html#parallel-dataflows

http://kafka.apache.org/

https://www.ovh.com/fr/together-book-2016/

https://letsencrypt.org/

https://www.symantec.com/products/threat-protection/data-center-security

http://git-scm.com/book/ca/Git-on-the-Server-Setting-Up-the-Server

https://www.ovh.com/fr/private-cloud/documentation/certifications.xml

http://www.vmware.com/fr/products/nsx.html

https://www.vaultproject.io/

http://docs.guzzlephp.org/en/latest/index.html

http://reactphp.org/

http://nginx.org/en/docs/http/load_balancing.html

http://www.haproxy.org/

https://doc.ubuntu-fr.org/rsync

http://global.qlik.com/fr

https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developing-requirements

https://fr.wikipedia.org/wiki/Internet_Corporation_for_Assigned_Names_and_Numbers

https://fr.wikipedia.org/wiki/Registre_Internet_régional

https://tools.ietf.org/html/rfc4966

https://fr.wikipedia.org/wiki/Network_address_translation

https://tools.ietf.org/html/rfc2460

https://fr.wikipedia.org/wiki/Path_MTU_discovery

https://fr.wikipedia.org/wiki/IPv6#Structure_de_l.27adresse_IPv6_unicast_globale

http://wso2.com/projects/wsf/java

http://socketo.me/

https://cycle.js.org/

http://msdn.microsoft.com/fr-fr/library/67ef8sbd.aspx


SMS SMSC

https://github.com/tony2001/coturn

http://www.kannel.org/

http://docs.jasminsms.com/en/latest/installation/index.html

http://linuxblog.darkduck.com/2014/01/sms-gateway-linux.html

https://www.amqp.org/


Smartphone

https://cordova.apache.org/

http://sebsauvage.net/wiki/doku.php?id=totp


Lecture

http://hello-finance.com/organisations-distribuees-autonomes-statut-juridique-thibverbiest-de-gaulle-fleurance-associes/

https://en.wikipedia.org/wiki/System_archetype

https://en.wikipedia.org/wiki/System_dynamics

https://en.wikipedia.org/wiki/Ergodicity#Markov_chains


Security

http://sebsauvage.net/wiki/doku.php?id=totp

https://fr.wikipedia.org/wiki/Kerberos_(protocole)

https://fr.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer

https://github.com/certbot/certbot

https://ovs.acunetix.com/#/configure/targets/list/

https://letsencrypt.org/

http://www.watchguard.com/

http://sebsauvage.net/wiki/doku.php?id=totp

https://github.com/travist/jsencrypt

http://www.root-me.org/?lang=fr

http://css.csail.mit.edu/mylar/#People

http://css.csail.mit.edu/mylar/#Applications

https://github.com/yahoo/gryffin

http://thpierre.developpez.com/articles/fuzzing/

https://github.com/strikeout/mylar

https://www.graylog.org/use-cases

http://mqtt.org/

Réalité et choix

Aucun choix encore envisagé, d'où la mise en "vrac" des liens/pistes utiles puisqu' il faut se connecter à la "sandbox" du régulateur et s'adapter à l'impact de la "dette technique" lié aux systèmes bancaires/finances vieillissants et/ou "immutable". Les APIs backend distribuées devant s'adapter à divers langages utilisés par les big values (Java, C#) et par les banques alternatives locales / web only / participatives (PHP) ... les liens en "vrac" seront donc utiles.

After some read, A lot of the job can be done by Kafka DB configurations (if consider: producers - AND & OR in some case - consumers) and - considered the pre-determinist configuration (part of) multi-levels tokens and unique-file one-stop-usage with few js code can be pre-generated and pre-registered in Kafka (except the "in-code" self-signed key for ~real-time stack usage as a part of the security). The few part end can be produced and done under akka.io. I think. (Excepted maybe the frontend and usage examples or we can generate the code needed by "bank and web professional enduser" when they subscribe under their bank web interface).


https://code.facebook.com/posts/302060973291128/open-sourcing-haxl-a-library-for-haskell/

http://scala-lang.org/documentation/

https://www.haskell.org/

https://www.playframework.com/

_____________________________

https://github.com/bigchaindb/bigchaindb/pulls

https://github.com/yahoo/pulsar/blob/master/docs/Architecture.md#managed-ledger

Basics of social networks hack
Empathy

  1. How will you attract the empathy from the customer?
  2. How will you sell the customer?s presumed needs(problem) to him/her?
  3. How will you convince the customer that your solution can solve that problem best?
Facilité de paiement
Sécurité des paiements par géolocalisation "fine grained" + limitation sur base volontaire.

Envisager, sur base volontaire et par géolocalisation, une automatisation partiel du processus de rechargement (ex. wallet de paiement banque) lorsque l'utilisateur "descend en ville" -> event "je suis en centre ville" -> j'ai signalé à ma banque qu'elle me propose de recharger mon "wallet de paiement facile" (par exemple pour une période de solde et un budget) -> je passe à côté d'un "distributeur de billet" -> le distributeur me propose automatiquement (sur mon smartphone via F-NFC amplifié, wifi, radio, ...) de recharger mon "portefeuille virtuel" avec une somme moyenne par défaut ou au choix.

Pré-token d' autorisations de paiements potentiels mais pas définitivement acceptés.
Simplicité et transparence

Chaque utilisateur final payant sur un site web / une app aura totalement l'impression d'être parfaitement connecté avec sa banque (Retour du logo de sa banque, recherche de sa banque via première lettres/chiffres swift/bic), url d'activation (si non-activé) pointant vers une page "marketing" de sa banque par sa banque, etc...

Dernières technologies

SASL principes

+

Multi-encryption à plusieurs niveaux (HDD, échanges, ip de confiances, entry point, encryption aussi au niveau réplication, protocole dédié, SSL, échanges de clés multiples à de multiples niveaux entre les différents "acteurs", mot de passe unique non transférable sur le réseau, clé à usage unique qui en découle, géolocalisation multiple, appareils de confiance + stacking + unique API-file signature associée ?? + API-file avec "one stop" usage et stacking-rolling-stacking pour les "usages de faux" (men-in-the-middle who remove ssl + facebook cookie catch + js catch + load the good partner web site to get a new unique payment url (or nextgen: a service worker interogation) + for a specific user... => stack(s) "slide" by knowed token ? + on-unique-usage-unique-url, key(s) rolling by "distributed" backend APIs, pwd stacking-rolling ?, unique url request-usage rolling-stacking, unique-usage-POST[]-linked-to, unique key(s), DBs separation + tables separations (driven-by-app-state ? + intra-secured-keys-by-usage ?), "random-thread-driven-negociation" ?, unique pwd translation, unique pwd + encryption stacking (intra private-public in some case), encryptions wall + wall bricks rolling => in-memory caching / boot => "regular" (even anarchy - on fake anarchist timers rolling ??) (re)boot randomization / instance ? => all mitigations system - like ASLR)

+ voir Mylar (+Verena) + Gryffin + watchgard

+ code obfuscator (with keys where keys go to a physical irl safe-deposit => irl-protocol (step-by-step) before begin to work / modify project and on few PCs on a small intranet only). Clean datas (by rewrite hdd-blocks - 7-10 pass). Only one PC connected to network to send obfuscated code through (pre-)tunnel(s)-deletion-by-usage ? or std tunnel or we go "on-site".

Etc... ?

____________________

Basics ?

canonical signature via items of the entire shop cart (as a stdised hash with reverse calculation ? microdatas ?), (dns sig, trusted machine, dynamic / self-defined geolocalization, and if necessary 1FA and/or 6 digits if family desktop configured under online bank account (but a good practice is child 1 account, adult 1 account, invited 1 account, etc...), unique bad values temp stacking (ip based) until the good process buyer end (something like ip-ip-ip-dns "loop"). ip near real-time update to securities vendors (firewall) -> (Business ? Billing ?).
Near real-time block.
____________________

Basics ?

https://www.youtube.com/channel/UC8butISFwT-Wl7EV0hUK0BQ

https://sourcemaking.com/design_patterns/observer

https://sourcemaking.com/design_patterns/iterator


http://kamranahmed.info/blog/2016/08/13/http-in-depth


Paiement "automatisé"

Véhicules, parking, péage, achat/recharge/paiement en déplacement, contenu payant, achat inApp, ...

Mission

  1. What is the object I do business?
  2. What is my promise to the customer?
  3. Are object and mission of company and the customer correspond with each other?
Mission

* Reconnecter banques et acteurs professionnels du web.

* Faciliter les paiements online (plus de funnel / tunnel)

* Sécuriser les paiements online (chaque paiement est géolocalisé et l'expérience de sécurité peut être personnel, personnalisée et personnalisable par les acteurs concernés)

* Sécuriser les paiements online (système "pré-déterminé" par token, multi-unique token, unique-file, unique-init, sur base volontaire, par géolocalisation, par "stacking" (multiple), ...)

* Donner l'accès à un marketing naturel (quasi-instantané) et non-profilé

* Taxe carbone monde ? Taxe recyclage monde ? Automatisée ? Volontariat fiscal ?

Market

  1. Is the importance of desire one customer feels enough?
  2. Is the number of total customers big enough?
  3. Is the feature of the business attractive to enter?
Marché

Big market: default payment (60% population usage) = 600 billions C.A. / year

3.6 billions internet users, 5.8 billions in 18 months...


Fast growth expected

Objectif: only partners

Advantage

  1. What are competitive goods, substitute goods, and alternative goods of the solution based on the customer?s problem?
  2. Did my solution have the comparative advantage competitors cannot look down on?
Prix

La meilleure app de paiement du moment n'est pas décentralisée-distribuée. Cependant, les technologies utilisées ont permis de faire descendre le prix à 0.04 euro / opération. Yapp devrait être à 0.001 euro / requête.

Pas de conccurent direct
La Fin du paiement tunnel / funnel
Paiement NFC sécurisé
Avantages banques (prévisions à moyen terme)

changement de paradigme (cash machine)
|
changement de paradigme (cash en wallet)
|
changement de paradigme (payment/wallet/(re)charge full automation when "by event" in some case - or simple one click "accept/reject" when "detection" or "on demand")

High Concept

  1. Does my concept have the sensitive/cultural aspect?
  2. What short and powerful slogan will you present?
  3. Can you make them your fan without persuasion?
Cultural 1

Ne pas détruire d'emplois dans la fintech et chez les "bigs values".

Cultural 2

Ne produire aucune cryptomonnaies.

Cultural 3

Sécurité par géolocalisation, unique token, "one stop" file usage, unique signature, ...

Cultural 4

Orienté enduser (performance, rapidité, transparence)

Cultural 5

Light footprint - Fintech can proudly become greenTech

Cultural 6

Orienté enduser + UX et corporate inApp, POS et web

Culltural 7

Cryptomonnaie interdite - on se recentre sur l'économie réelle.

Cultural 8

All encrypted in a unique way as possible (Europe exigence).

A-prioris

Facebook (ou autre réseau social) connaitra-t-il mes habitudes d'achats ?

Non Facebook ne connaitra rien de vos achats.

Est-ce que les données Facebook (ou autre réseau social) seront partagées ?

Non, le site web où vous payez ne connaitra rien de votre/vos activités sur les réseaux sociaux lors de votre achat, votre banque non plus.

Quelle donnée récupérez-vous de mon compte Facebook (ou autre réseau social) ?

Nous n'utiliserons que votre adresse mail qui sera cryptée et les données de paiements (cryptées) comme la somme et une signature de sécurité spécifique seront fournies uniquement à votre banque. Uniquement le commerçant sera susceptible de récupérer votre panier d'achat sur son site web ou son application (livraison, facturation, etc...).

https://cispe.net/

Des produits à forte valeur ajoutée apparaitront. Mais aucun produit/plugin/option/extension ajoutée ne recueillera des données sans votre accord préalable et le détail vous sera fourni (toujours à ces mêmes finalités: automatisation de la facturation, automatisation du paiement - avec NFC actif, etc...).

Pattern tokens implies

* On peut imaginer la recharge électrique d'un véhicule (de n'importe quel type) à l'ext. d'une maison (peut importe à qui elle appartient - cqfd: pattern tokens / smartcontract).

Ainsi, n'importe quel véhicule peut potentiellement se charger n'importe où, même chez un voisin, un ami, même en chemin via un chargeur sans contact (une autoroute, etc...) .... On peut donc diminuer grandement, mais progressivement, la taille des batteries tout au long du déploiement autoroutier.

Exploring Opportunities

  1. What are the new opportunity factors concerning the change of business environment?
  2. How are customer needs or customer?s life style changing?
  3. What is the part to look at carefully in terms of social culture?
  4. What are the contents of the technology change that will affect in a middle and long term?
  5. What are the customer?s needs that do not change regardless of this change?
  6. Besides, does the remarkable new business exist?
Paiement accéléré

Les paiement en ligne s'en trouve accélérés (plus de funnel/tunnel nécessaire etc...)

Paiement décentralisé

En décentralisant cette activité de paiement en ligne, on augmente les possibilités de rémunération des réseaux sociaux (capacité à intégrer du contenu payant, leur permettre d' envisager des partenariats avec certaines industries, ...).

Changement de paradigme progressif - business model.

Pas de concurrence ?

La solution sera "intégrable" par les systèmes de paiements actuels (les "big values" ainsi que les nouvelles applications de type "start-up" de la "Fintech").

Objectif à moyen terme

Suffisamment disruptif pour faire adopter la solution comme moyen de paiement "par défaut" ? (60% usage)

Impactes à plus long terme

Contenus en vente IRL pouvant se retrouver "en contenu payant" ou "à accès payant" depuis chaque réseau social, depuis chaque publicité, depuis chaque site web, ... via un processus d'achat accéléré et non-profilé.

Changement de paradigme - marketing ads.

Revenue

  1. What is the main revenue source of my business?
  2. What will account for the greatest portion among revenue source?
  3. What is the revenue source you can secure from the beginning?
  4. What is the total life time value while securing one customer?
Facturation

Le business modèle repose sur la transition des données.

Yapp facture 1 euro / millier requête à chaque banque. Libre à chaque banque de pratiquer ensuite sa propre politique de prix / sur mesure / par client, etc...

Learn & Pivot

  1. What are the indexes to measure for the hypothesis confirmation during action? (After Action)
  2. What caused the difference between the action result and hypothesis?
  3. Is it enough by partial control? Do you need a big change?
Lean et pivot suivant recette et dépenses

Paiement taxe à 3 ans => pdt 2 ans activité

98.5 part de recette
1.5 part de dépense

~ et en l'état actuel et dans l'esprit "stay small think big".

La part "valuable" (smart value) se situe à 75/25

Ce qui laisse une marge d'adaptation de 23.5% au(x) contrainte(s), contraintes que je pourrais constater une fois connecté à la "sandbox".

A 50/50, donc sans mettre en péril la viabilité (et sans augmenter la promesse du prix facturé), les arguments resteront transparence de la distribution du produit / pas de "marque/label", facilité de paiement, libéralisation du marché, automatisation, sécurisation, etc...

On a une marge de 1k % pour rester moitié moins chère que l'unique "concurrent". (2 requêtes / opération).

Les "contraintes" (taxation imprévue, système informatique bancaire vieillissant, "dette technologique" propre - cqfd: impact des principes de sécurités / performance visée, ...), desquelles je dois adaptés l'idée / le dev., ne feront qu'augmenter les ressources serveurs consommées (+ dette "technique" "bank/market" du à l' "immutable" ou à la disruptivité) et ne devraient avoir aucun autre impact. Avec ce type de marge (d'ajustement au démarrage ou d'ajustement concurrentiel), çà devrait aller.

Cost

  1. What is the main cost structure of my business?
  2. What is the fixed cost item? (independent sales)
  3. What is the variable cost item? (subordinate sales)
  4. How much it cost to secure/maintain one customer?
2x private cloud + serveurs

En commençant, la charge serveur devrait être à 1500 euros le premier mois (afin de tester aussi tous les aspects en condition "réelle" mais en mode "bac à sable").

Le deuxième mois, il faut encore calculer la charge et la scalabilité nécessaire.

Au début du troisième mois, il y a des rentrées (facturation à 30 jours fin de mois).

2 x private cloud en VPN pour profiter des 10Gbps fibre OVH intra.

Frais architectures décentralisés

3 mois de location avant rentabilité

2000 euros / mo (2 x private cloud)

/!\ peut grandement varié suivant la charge serveur(s) dès le début du deuxième mois (mais s'il y a scalabilité dût à la charge c'est qu'il y aura les rentrées nécessaires aux paiements des frais afférents)

Frais divers et charges (VPS instance autoboot/autoscale + HDDs)

500 euros / mo

/!\ Peut grandement varié aussi (pour les mêmes raisons)

Salaires à 3 mois

Owner / CEO

4500

1 développeur expert en sécurité (ou en fin de mon dev. mettre en place un concours white hack). Bien que le salaire sera peu élevé alors que le travail pendant quelques semaines / mois sera intensif, je me baserais sur les pratiques actuelles du business zéroday afin qu'il ait une prime finale basée sur les prix moyens des types de failles découvertes et qui lui sera versée dès les premières rentrées financières (double prime puisque zeroday "public" plateforme bonus).

Cependant, le salaire standard doit être versé, 6000 (avantages divers, exempt charge patronale ?).

1 spécialiste marketing moderne (web et app) surtout avec compétences en gestion marketing et financière - futur CFO et/ou CMO ??

6000 (extra 3% equity - peut être révisé à la baisse puisque j'ai pu constaté que traditionnellement c'est plutôt 0.1 à 1% si salaire)


Aménagements et bâtiment à 3 mois (seed)

Bureau en location avec capacité d' accueil client

2400

Matériels informatiques et techs

6000

Politique de sécurité intra et matériels associés

13000

Consultations externes

6000

Divers et imprévus

12% amount: ~5500 à ~6500

Audit de sécurité (politique de sécurité intra et black boxing)

10000

Peut être optionnel ou obligatoire

PCI DSS 1 + SOC I type 1 + SOC II type 2

coût ?


Powered by canvanizer.com
Try out Canvanizer 2.0