Προγραμματιζόμενες Πληρωμές: Κανόνες, APIs και Έξυπνα Συμβόλαια

Σκεφτείτε ένα τιμολόγιο που πρέπει να πληρωθεί μόνο μετά την άφιξη των εμπορευμάτων, όταν ένας αισθητήρας επιβεβαιώνει ότι η θερμοκρασία παρέμεινε εντός ορίου, και και οι δύο εταιρείες εγκρίνουν την τελική ποσότητα. Μια προγραμματιζόμενη πληρωμή μπορεί να συντονίσει αυτές τις προϋποθέσεις. Δεν μπορεί, με μαγεία, να αποφασίσει αν ο αισθητήρας είναι αξιόπιστος ή αν η νομική σύμβαση εκπληρώθηκε.

Η προγραμματισιμότητα φέρνει τους επιχειρηματικούς κανόνες πιο κοντά στη ροή των χρημάτων. Το πολύτιμο δεν είναι η καινοτομία στον κώδικα· είναι η δυνατότητα να γίνονται οι προϋποθέσεις σαφείς, δοκιμαστές και συνδεδεμένες με μια αρχή πληρωμών που παραμένει περιορισμένη.

Μια προγραμματιζόμενη πληρωμή είναι μια μεταφορά της οποίας η έναρξη, το ποσό, ο χρονισμός ή ο προορισμός διέπεται από κανόνες εκτελέσιμους από μηχανή. Ο κανόνας μπορεί να βρίσκεται σε κανονικό λογισμικό εφαρμογής, στη μηχανή ροής εργασιών μιας τράπεζας ή σε ένα έξυπνο συμβόλαιο. Συνεπώς, η προγραμματισιμότητα δεν είναι συνώνυμη με το blockchain. Το σημαντικό είναι ότι οι καθορισμένες προϋποθέσεις αξιολογούνται και ένα εξουσιοδοτημένο σύστημα προκαλεί τη μετακίνηση των χρημάτων.

Οι προγραμματιζόμενες πληρωμές δεν είναι απαραίτητα προγραμματιζόμενο χρήμα. Μια συμβατική τραπεζική κατάθεση μπορεί να μετακινηθεί με κανόνες λογισμικού ενώ το χρήμα αυτό καθαυτό διατηρεί τις συνηθισμένες ιδιότητές του. Το προγραμματιζόμενο χρήμα θα ενσωμάτωνε ή θα επιβάλλει προϋποθέσεις στο επίπεδο του χρηματοοικονομικού οργάνου ή του λογιστικού βιβλίου. Η διατήρηση αυτής της διάκρισης αποτρέπει το χαρακτηρισμό μιας λειτουργίας αυτοματοποίησης ως νέου τύπου χρήματος.

Προγραμματιζόμενες Πληρωμές σε Μία Ματιά

Η διαδικασία ξεκινά με μια εντολή, τη μετατρέπει σε ντετερμινιστικές προϋποθέσεις, συλλέγει αξιόπιστες εισροές, αξιολογεί τον κανόνα, υποβάλλει μια πληρωμή μέσω εξουσιοδοτημένου καναλιού και καταγράφει το αποτέλεσμα. Ένα έξυπνο συμβόλαιο μπορεί να εκτελέσει πολλά βήματα, αλλά εξακολουθεί να εξαρτάται από ταυτοποιήσεις, πηγές δεδομένων, περιουσιακά στοιχεία και νομικές συμφωνίες εκτός του κώδικά του.

Ποιος Κάνει Τι στις Προγραμματιζόμενες Πληρωμές;

Ο πληρωτής ορίζει την αρχή· το λογισμικό αξιολογεί τις προϋποθέσεις· ένα oracle ή API παρέχει τα δεδομένα· μια τράπεζα, εκδότης stablecoin ή λογιστικό βιβλίο μετακινεί το περιουσιακό στοιχείο· και ένας χειριστής διαχειρίζεται τις εξαιρέσεις. Ο οδηγός μας για έξυπνα συμβόλαια εξηγεί το επίπεδο κώδικα, ενώ Επεξήγηση του Paxos δείχνει γιατί το στοιχείο διακανονισμού και ο εκδότης παραμένουν διακριτά.

Ένας χρήσιμος τρόπος αξιολόγησης των Προγραμματιζόμενων Πληρωμών είναι να ξεκινάτε από το τέλος αντί για την αρχή. Ρωτήστε τι μπορεί τελικά να διεκδικήσει ο παραλήπτης, ο επενδυτής ή ο οργανισμός μετά την καταγραφή αποτελέσματος, και στη συνέχεια εντοπίστε αυτό το αποτέλεσμα πίσω μέσω της επικύρωσης μέχρι τις αποδείξεις που αποδεχθήκαν στο ορισμό κανόνα. Κάθε μετάβαση πρέπει να ονομάζει το αρχείο που άλλαξε, την αρχή που το αποδέχτηκε και την προϋπόθεση που θα έκανε τη μετάβαση άκυρη. Αν το μονοπάτι τελειώνει σε μήνυμα πίνακα ελέγχου ή κατάσταση προμηθευτή, το σύστημα έχει περιγράψει ένα γεγονός διεπαφής· όχι απαραίτητα ένα εκτελέσιμο αποτέλεσμα.

Ο χάρτης ευθυνών έχει σημασία για τον ίδιο λόγο. Ο δημιουργός κανόνα και το στρώμα διακυβέρνησης μπορεί να συμμετέχουν και τα δύο σε ένα ταξίδι πελάτη, αλλά δεν υπόσχονται το ίδιο ούτε διατηρούν τις ίδιες αποδείξεις. Όταν μια εταιρεία αναθέτει εξωτερικά μια λειτουργία, το λειτουργικό έργο μπορεί να μετακινηθεί ενώ η νομική υποχρέωση, η σχέση με τον πελάτη ή η υποχρέωση απορρόφησης μιας ζημίας παραμένει πίσω. Μια σοβαρή αξιολόγηση θα πρέπει, επομένως, να ρωτήσει ποιος μπορεί να διορθώσει το εξουσιοδοτημένο αρχείο, ποιος χρηματοδοτεί μια εξαίρεση και ποιος συμμετέχων πρέπει να συνεχίσει τη λειτουργία εάν ένας προμηθευτής αποτύχει στη χειρότερη δυνατή στιγμή.

Τέλος, δοκιμάστε δύο αποτυχίες μαζί αντί για μία τη φορά: κακή προδιαγραφή μαζί με αμεταστροφή. Τα πραγματικά περιστατικά σπάνια σέβονται τα καθαρά όρια ενός διαγράμματος διαδικασίας. Ένας έλεγχος είναι αξιόπιστος μόνο αν οι συμμετέχοντες μπορούν να διατηρήσουν το σωστό ισχυρισμό, να ανασυνθέσουν τη σειρά, να επικοινωνήσουν την καθυστέρηση και να φθάσουν σε μια εναρμονισμένη κατάσταση χωρίς να εφεύρουν δεύτερη έκδοση της συναλλαγής. Αυτή η δοκιμή μετατρέπει τα Programmable Payments από μια ετικέτα μάρκετινγκ σε ένα σύστημα που μπορεί να εξεταστεί.

Πού πρέπει να συμφωνούν τα αρχεία των Programmable Payments

Ένας κανόνας μπορεί να εκτελεστεί σωστά ενάντια σε λανθασμένη είσοδο. Αυτό παράγει ένα τεχνικά έγκυρο αλλά οικονομικά λανθασμένο αποτέλεσμα. Η αλυσίδα ελέγχου πρέπει επομένως να συνδέει την αρχική εντολή, την προέλευση των δεδομένων, την έκδοση του κανόνα, την εξουσιοδότηση, το αναγνωριστικό της συναλλαγής και την τελική κατάσταση του λογιστικού βιβλίου.

Πώς λειτουργούν τα Programmable Payments

1. Ορισμός κανόνα στα Programmable Payments

Ο κανόνας πρέπει να είναι πιο ακριβής από την επιχειρηματική πρόταση. «Πληρωμή όταν φτάσουν τα εμπορεύματα» απαιτεί ορισμούς για τα εμπορεύματα, τον προορισμό, την επιθεώρηση, το χρόνο, τη μερική παράδοση και τη διαφορά. Ο κώδικας μπορεί να εκτελέσει μόνο την κατάσταση που λαμβάνει. Η ασάφεια δεν εξαφανίζεται· μετακινείται στις ορισμούς δεδομένων και στη διακυβέρνηση.

2. Παρατήρηση γεγονότος στα Programmable Payments

Μια ροή εργασίας που ενεργοποιείται από API μπορεί να ερωτήσει μια υπηρεσία εφοδιαστικής αλυσίδας και να στείλει μια τραπεζική πληρωμή μετά την έγκριση. Ένα έξυπνο συμβόλαιο μπορεί να κρατήσει ένα τοκενιζόμενο περιουσιακό στοιχείο ή εντολή και να εκτελεστεί όταν ικανοποιηθούν οι συνθήκες στο λογιστικό βιβλίο. Οι αρχιτεκτονικές διαφέρουν ως προς την εμπιστοσύνη και την εκκαθάριση, αλλά και οι δύο χρειάζονται πιστοποιημένα δεδομένα και περιορισμένη εξουσία.

3. Επικύρωση στα Programmable Payments

Το πρόβλημα του oracle προκύπτει όταν ένας ψηφιακός κανόνας εξαρτάται από τον φυσικό κόσμο. Ένας αισθητήρας μπορεί να αποτύχει· ένας πάροχος δεδομένων μπορεί να υποκλαπεί· πολλαπλές πηγές μπορεί να διαφωνούν. Οι ανθεκτικές σχεδιάσεις καθορίζουν ιεραρχία πηγών, ανοχές, περιόδους αμφισβήτησης και μια ασφαλή κατάσταση αντί να υποθέτουν ότι τα δεδομένα είναι αλήθεια.

4. Ατομική εκτέλεση στα Programmable Payments

Η ατομική εκκαθάριση συνδέει τις αλλαγές έτσι ώστε είτε να συμβούν όλες είτε καμία. Η παράδοση‑αντί‑πληρωμή είναι το κλασικό παράδειγμα: το περιουσιακό στοιχείο μεταβιβάζεται μόνο αν η πληρωμή μεταβιβαστεί. Η ατομικότητα μπορεί να μειώσει τον κύριο κίνδυνο, ωστόσο μπορεί να αυξήσει τη ζήτηση ρευστότητας επειδή κάθε απαιτούμενο περιουσιακό στοιχείο πρέπει να είναι διαθέσιμο ταυτόχρονα.

5. Καταγραφή αποτελέσματος στα Programmable Payments

Οι έλεγχοι πρέπει να βρίσκονται τόσο έξω όσο και μέσα στον κανόνα. Η ταυτοποίηση, οι κυρώσεις, τα όρια δαπανών, οι εκτάκτες διακοπές και οι διαδικασίες αναβάθμισης είναι λειτουργίες διακυβέρνησης. Ένα αυτοεκτελούμενο συμβόλαιο χωρίς έγκυρη διαδικασία εξαίρεσης μπορεί να αυτοματοποιήσει το λανθασμένο αποτέλεσμα πιο αποδοτικά.

Η οικονομική πλευρά των Programmable Payments

Η προγραμματισιμότητα μειώνει το συντονισμό και την εξιλέωση όταν πολλές ενέργειες μοιράζονται μια επαληθεύσιμη προϋπόθεση. Η εγγύηση, η χρηματοδότηση εφοδιαστικής αλυσίδας, τα δικαιώματα, οι κλήσεις εγγυήσεων και η χρέωση βάσει χρήσης μπορούν όλα να ωφεληθούν.

Οι εξοικονομήσεις είναι μεγαλύτερες όπου η σημερινή διαδικασία περιλαμβάνει επαναλαμβανόμενα μηνύματα, χειροκίνητες αποδείξεις και αβέβαιες μεταβιβάσεις. Εάν η αρχική διαδικασία είναι ήδη μια απλή άμεση χρέωση, η προσθήκη ενός σύνθετου λογιστικού βιβλίου μπορεί να αυξήσει το κόστος.

Η συνθεσιμότητα επιτρέπει στους κανόνες να συνδέονται, αλλά η εξάρτηση αυξάνεται με κάθε εξωτερικό συμβόλαιο και πηγή δεδομένων. Η χρηματοοικονομική αποδοτικότητα πρέπει να μετράται έναντι του σχετικού κινδύνου λογισμικού, oracle και διακυβέρνησης.

Τρόποι αποτυχίας στα Programmable Payments

• Κακή προδιαγραφή: Ο κώδικας μπορεί να εκτελέσει πιστά έναν κανόνα που δεν ταιριάζει με την εμπορική συμφωνία.
• Αποτυχία Oracle: Το γεγονός έναρξης μπορεί να είναι ψευδές, παρωχημένο, μη διαθέσιμο ή στρατηγικά χειραγωγημένο.
• Αντιστρεψιμότητα: Η αυτόματη τελική τακτοποίηση μπορεί να αφήσει λίγο χρόνο για να σταματήσει η απάτη ή να διορθωθούν τα σφάλματα εισόδου.
• Συνθετότητα: Μια αποτυχία σε ένα συνδεδεμένο συμβόλαιο μπορεί να εξαπλωθεί μέσω άλλων, διαφορετικά υγιών συναλλαγών.
• Αρχή: Πρέπει να είναι σαφές ποιος μπορεί να διακόψει, να αναβαθμίσει, να αμφισβητήσει ή να παρακάμψει τον μηχανισμό.

Παράδειγμα Εφαρμοσμένης Προγραμματιζόμενης Πληρωμής

Σκεφτείτε μια μίσθωση εξοπλισμού που τιμολογείται βάσει επαληθευμένης χρήσης μηχανής. Ένας αισθητήρας αναφέρει τις λειτουργικές ώρες· το λογισμικό επικυρώνει τη συσκευή και συγκρίνει τη χρήση με τη σύμβαση· ο λογαριασμός του πληρωτή εγκρίνει ένα ανώτατο ποσό· και μια οδηγία πληρωμής εκδίδεται μηνιαίως. Ένα πιο ενσωματωμένο τοκενισμένο σύστημα θα μπορούσε να ενημερώνει ταυτόχρονα το εισπρακτέο της μίσθωσης και την πληρωμή. Σε κάθε σχεδίαση, οι δύσκολες ερωτήσεις είναι οι ίδιες: ποιος επικυρώνει τον αισθητήρα, τι συμβαίνει αν είναι εκτός σύνδεσης, μπορεί ο πελάτης να αμφισβητήσει την ανάγνωση και ποιο βιβλίο αποδεικνύει την τελική πληρωμή;

Αποδείξεις Πίσω από τις Προγραμματιζόμενες Πληρωμές

Το BIS συνεχής τοκενισμός και το σχέδιο μελλοντικού νομισματικού συστήματος εξηγούν πώς τα κοινά βιβλία και η προγραμματισιμότητα μπορούν να συνδυάσουν μηνύματα, περιουσιακά στοιχεία και τακτοποίηση. Επιπλέον, καθιστούν σαφές ότι τα θεσμικά και διακυβερνητικά επίπεδα παραμένουν.

Το έγγραφο της Federal Reserve για τεχνολογία κατανεμημένου βιβλίου στις πληρωμές, εκκαθάριση και τακτοποίηση αποτελεί ένα χρήσιμο αντισταθμιστικό στοιχείο στα καθαρά κώδικα αφηγήματα, επειδή θέτει σε πλαίσιο τόσο τις ευκαιρίες όσο και τις λειτουργικές προκλήσεις.

Τι Αλλάζει στις Προγραμματιζόμενες Πληρωμές;

Το BIS περιγράφει την τοκενισμό ως συνδυασμό πληροφοριών για περιουσιακά στοιχεία και ιδιοκτησία με κανόνες πλατφόρμας και διακυβέρνηση. Η έρευνα ενιαίων βιβλίων εξετάζει την τοποθέτηση τοκενισμένου χρήματος κεντρικής τράπεζας, εμπορικού τραπεζικού χρήματος και περιουσιακών στοιχείων σε ένα κοινό προγραμματιζόμενο περιβάλλον. Σε πιο κοντινό μέλλον, τα APIs και οι υπηρεσίες request-to-pay θα κάνουν τις συμβατικές καταθέσεις πιο υπό όρους και αυτοματοποιημένες. Το μέλλον πιθανότατα θα είναι υβριδικό: ρυθμιζόμενο χρήμα, προγραμματιζόμενες ροές εργασίας και επιλεκτικά κοινά βιβλία συνδεδεμένα με σαφείς ελέγχους.

Ερωτήσεις που Πρέπει να Θέσετε για τις Προγραμματιζόμενες Πληρωμές

• Στο ορισμό κανόνα, ποιο αρχείο αποδεικνύει ότι τα μέρη καθορίζουν την προϋπόθεση, την εξουσία, το ποσό, τον προορισμό και τη λήξη.
• Στην παρατήρηση γεγονότος, ποιο αρχείο αποδεικνύει ότι τα αξιόπιστα δεδομένα δείχνουν αν η προϋπόθεση έχει συμβεί.
• Στην επικύρωση, ποιο αρχείο αποδεικνύει ότι το λογισμικό ελέγχει την ταυτότητα, τα δικαιώματα, τα κεφάλαια, την πολιτική και την κατάσταση του κανόνα.
• Στην εκτέλεση ατομικά, ποιο αρχείο αποδεικνύει ότι η πληρωμή και το συνδεδεμένο περιουσιακό στοιχείο ή η ενημέρωση του αρχείου γίνονται ταυτόχρονα ή καθόλου.
• Στην καταγραφή αποτελέσματος, ποιο αρχείο αποδεικνύει ότι το σύστημα διατηρεί αποδείξεις, κατάσταση, εξαιρέσεις και τυχόν υπόλοιπες υποχρεώσεις.

Τι Να Διαβάσετε Μετά τις Προγραμματιζόμενες Πληρωμές

Για να δείτε πού κατευθύνεται αυτό, διαβάστε Πώς η Τοκενισμός και η Αυτόνομη Πληρωμή Θα Μεταμορφώσουν τις Πληρωμές. Για τη θεμελιώδη ταξινομία των περιουσιακών στοιχείων, συνεχίστε με Εξήγηση Ψηφιακών Περιουσιακών Στοιχείων.

Τα Συμπεράσματα των Προγραμματιζόμενων Πληρωμών

Το προγραμματιζόμενο χρήμα είναι πιο χρήσιμο όταν περιορίζει την ευσυνειδησία και παράγει καλύτερες αποδείξεις. Εάν η πηγή δεδομένων, η εξουσία παράκαμψης ή η διαδρομή ανάκτησης είναι ασαφείς, η αυτοματοποίηση κάνει το σφάλμα πιο γρήγορο αντί να κάνει την πληρωμή πιο έξυπνη.

Πηγές για τις Προγραμματιζόμενες Πληρωμές

• BIS: Η Συνεχής Τοκενισμού
• Σχέδιο BIS για το μελλοντικό νομισματικό σύστημα
• BIS: Το μελλοντικό νομισματικό σύστημα από το όραμα στην πραγματικότητα
• Federal Reserve: DLT στις Πληρωμές, Εκκαθάριση και Τακτοποίηση